Comment Python Web frameworks, WSGI et CGI s'articulent

je pense Florian réponse réponses de la partie de votre question au sujet de "qu'est-ce que WSGI", surtout si vous lisez PEP .

quant aux questions que vous posez vers la fin:

WSGI, CGI, FastCGI etc. sont tous les protocoles pour un serveur web à exécuter le code , et de livrer le contenu dynamique qui est produit. Comparez ceci à un service Web statique, où un fichier HTML simple est essentiellement livré tel quel au client.

CGI, FastCGI et SCGI de langue sont agnostiques. vous pouvez écrire des scripts CGI en Perl, Python, C, bash, n'importe quoi. CGI définit qui exécutable sera appelé, sur la base de l'URL, et comment il sera appelé: les arguments et l'environnement. Il définit également comment la valeur de retour doit être transmise au serveur web une fois que votre exécutable est terminé. Le les variations sont essentiellement des optimisations pour pouvoir traiter plus de requêtes, réduire la latence et ainsi de suite; le concept de base est le même.

WSGI est Python. plutôt qu'un protocole de langage agnostique, une fonction de signature standard est définie:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

qui est une demande WSGI complète (si limitée). Un serveur web avec le support WSGI (comme Apache avec mod_wsgi) peut invoquer cette fonction chaque fois qu'une requête arrive.

la raison pour laquelle c'est si génial, c'est que nous pouvons éviter l'étape confuse de la conversion D'un HTTP GET/POST à CGI en Python, et revenir à nouveau sur le chemin de la sortie. C'est un lien beaucoup plus direct, propre et efficace.

cela rend également beaucoup plus facile d'avoir des cadres de longue durée fonctionnant derrière des serveurs web, si tout ce qui doit être fait pour une demande est un appel de fonction. Avec un CGI simple, vous devez démarrer votre cadre complet pour chaque demande individuelle.

pour avoir le support WSGI, vous devez avoir installé un module WSGI (comme mod_wsgi ), ou utiliser un serveur web avec WSGI cuit in (comme CherryPy ). Si ni L'un ni l'autre n'est possible, vous pourrait utiliser le pont CGI-WSGI donné dans le PEP.

vous pouvez exécuter WSGI sur CGI comme Pep333 démontre comme un exemple. Cependant, chaque fois qu'il y a une requête, Un nouvel interpréteur Python est lancé et le contexte complet (connexions de base de données, etc.) est activé.) doit être construit qui tous prennent du temps.

le mieux si vous voulez lancer WSGI serait que votre hôte installe mod_wsgi et fasse une configuration appropriée pour reporter le contrôle à une de vos applications.

Flup est une autre façon de courir avec WSGI pour n'importe quel serveur web qui parle FCGI , SCGI ou AJP. D'après mon expérience, seul FCGI fonctionne réellement, et il peut être utilisé dans Apache via mod_fastcgi ou si vous pouvez exécuter un démon Python séparé avec mod_proxy_fcgi .

WSGI est un protocole similaire à CGI, qui définit ensemble de règles comment le serveur web et le code Python peuvent interagir, il est défini comme Pep333 . Cela permet à de nombreux serveurs web différents d'utiliser de nombreux cadres et applications différents en utilisant le même protocole d'application. C'est très bénéfique et ça rend ça très utile.

si vous n'êtes pas clair sur tous les termes de cet espace, et si vous le permettez, c'est un acronyme confus-chargé, il y a aussi un bon lecteur de fond sous la forme d'un HOWTO python officiel qui traite de CGI vs. FastCGI vs. WSGI et ainsi de suite: http://docs.python.org/howto/webservers.html

c'est une simple couche d'abstraction pour Python, semblable à ce que la spécification Servlet est pour Java. Alors que CGI est vraiment bas niveau et ne fait que balancer des trucs dans l'environnement process et standard in/out, les deux spécifications ci-dessus modélisent la requête et la réponse http comme des constructions dans le langage. Mon impression est cependant qu'en Python les gens n'ont pas tout à fait réglé sur les implémentations de facto donc vous avez un mélange d'implémentations de référence, et d'autres bibliothèques de type utilitaire qui fournissent d'autres choses. avec le support WSGI (par ex. Paste). Bien sûr que je peux me tromper, je suis un nouveau venu en Python. La communauté des "scripts web" s'attaque au problème dans une direction différente (hébergement partagé, héritage CGI, préoccupations de séparation des privilèges) que les gens de Java ont eu le luxe de commencer avec (exécuter un conteneur d'entreprise unique dans un environnement dédié contre code compilé et déployé statiquement).