Comment Python web frameworks, WSGI et CGI s’emboîtent

Question

J'ai un Bluehost compte où je peux exécuter des scripts Python en tant que CGI. Je suppose que c'est le plus simple CGI, parce que j'ai à définir les éléments suivants, en .htaccess:

Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py

Maintenant, chaque fois que je regarde la programmation web avec Python, je entendons beaucoup parler de WSGI et la façon dont la plupart des cadres de l'utiliser. Mais je ne comprends pas comment il s'adapte à tous ensemble, en particulier lorsque mon serveur web (Apache en cours d'exécution à un hôte de la machine) et non pas quelque chose que je peux vraiment jouer avec (à l'exception de la définition d' .htaccess des commandes).

Comment sont WSGI, CGI, et les cadres tous connectés? De quoi ai-je besoin de savoir, d'installer et de faire si je veux exécuter un framework web (dire web.py ou CherryPy) sur ma base de configuration CGI? Comment faire pour installer WSGI de soutien?

Answer 1

Comment WSGI, CGI, et les cadres sont tous connectés ?

Apache écoute sur le port 80. Il reçoit une requête HTTP. Il analyse la demande de trouver un moyen de répondre. Apache a BEAUCOUP de choix pour répondre. Une façon d'y répondre est d'utiliser des CGI pour exécuter un script. Une autre façon d'y répondre est d'être simplement un fichier.

Dans le cas de CGI, Apache prépare un environnement et invoque le script par le protocole CGI. C'est un standard d'Unix Fork/Exec situation -- le CGI sous-processus hérite d'un environnement de système d'exploitation, y compris la prise et la sortie standard (stdout). Le CGI sous-processus écrit une réponse, qui remonte à Apache; Apache envoie cette réponse au navigateur.

CGI est primitif et ennuyeux. Surtout parce qu'il les fourches d'un sous-processus pour chaque demande.

WSGI est une interface basée sur le CGI modèle de conception. Il n'est pas nécessairement CGI -- il n'a pas à fourche d'un sous-processus pour chaque demande. Il peut être CGI, mais il n'a pas à être.

WSGI ajoute à la CGI modèle de conception de plusieurs façons importantes. Il analyse les en-Têtes de Requête HTTP pour vous et ajoute de ces de l'environnement. Il fournit toute l'après-entrée orientés vers un fichier comme objet dans l'environnement. Il vous offre également une fonction qui permettra de formuler la réponse, vous sauver de beaucoup de détails de mise en page.

De quoi ai-je besoin de savoir / installer / faire si je veux exécuter un framework web (dire web.py ou cherrypy) sur ma base de configuration CGI ?

Rappelons que la fourche d'un sous-processus est coûteux. Il y a deux façons de contourner cela.

1. Incorporé mod_wsgi ou mod_python incorpore Python à l'intérieur de Apache; aucun processus n'est fourchue. Apache s'exécute l'application Django directement.

2. Démon mod_wsgi ou mod_fastcgi permet à Apache d'interagir avec un démon (ou "long processus en cours d'exécution"), à l'aide de la WSGI protocole. Vous démarrez votre longue Django processus, vous devez ensuite configurer Apache mod_fastcgi pour communiquer avec ce processus.

Notez que mod_wsgi peut fonctionner dans les deux modes: intégré ou démon.

Quand vous lisez sur mod_fastcgi, vous verrez que Django utilise flup pour créer un WSGI-interface compatible à partir de l'information fournie par mod_fastcgi. Le pipeline fonctionne comme ceci.

Apache -> mod_fastcgi -> FLUP (via CGI protocol) -> Django (via WSGI protocol)

Django a plusieurs "django.de base.gestionnaires" pour les différentes interfaces.

Pour mod_fastcgi, Django fournit un manage.py runfcgi qui intègre FLUP et le gestionnaire.

Pour mod_wsgi, il y a un gestionnaire de base pour cela.

Comment faire pour installer WSGI de soutien ?

Suivez ces instructions.

http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

Pour plus d'information, voir ce

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index

Answer 2

Je pense que Florian réponse répond à la partie de votre question sur "qu'est-ce que WSGI", surtout si vous lisez le PEP.

Comme pour les questions que vous posez vers la fin:

WSGI, CGI, FastCGI, etc. sont tous les protocoles pour un serveur web pour exécuter du code, et de livrer le contenu dynamique qui est produite. Comparez cela à web statique de servir, où un fichier HTML est fondamentalement remis comme c'est pour le client.

CGI, FastCGI et SCGI de langue sont agnostiques. Vous pouvez écrire des scripts CGI en Perl, Python, C, bash, que ce soit. CGI définit qui exécutable sera appelé, en fonction de l'URL, et comment il sera appelé à: l'argumentation et de l'environnement. Il définit également la façon dont la valeur de retour doit être transmise au serveur web une fois que votre exécutable est terminé. Les variations sont essentiellement des optimisations pour être en mesure de traiter plus de demandes, de réduire la latence et ainsi de suite; le concept de base est le même.

WSGI est Python. Plutôt qu'une langue agnostique protocole, une fonction standard de signature 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']

C'est une complète (si elle est limitée) application WSGI. Un serveur web avec WSGI de soutien (comme Apache avec mod_wsgi) peut appeler cette fonction à chaque fois qu'une requête arrive.

La raison pour cela est si grand, c'est que nous pouvons éviter le sale l'étape de la conversion de un HTTP GET/POST de CGI Python, et à l'arrière à nouveau sur le chemin. C'est beaucoup plus direct, propre et efficace de la liaison.

Il rend également beaucoup plus facile de longue durée, les cadres de courir derrière des serveurs web, si tout ce qui doit être fait pour demande est un appel de fonction. Avec la plaine CGI, vous devrez commencer votre structure en place pour chaque demande individuelle.

Pour avoir WSGI de l'aide, vous aurez besoin d'avoir installé un module WSGI (comme mod_wsgi), ou l'utilisation d'un serveur web avec WSGI cuit (comme CherryPy). Si aucune de ces sont possibles, vous pourriez utiliser le CGI-WSGI pont donnée dans le PEP.

Answer 3

Vous pouvez exécuter WSGI plus de CGI comme Pep333 montre comme un exemple. Cependant chaque fois, il y a une demande d'un nouvel interpréteur Python est démarré et l'ensemble du contexte (connexions de base de données, etc.) doit être mise en place, qui tous prennent du temps.

Le mieux si vous souhaitez exécuter WSGI serait si votre hôte serait d'installer mod_wsgi et fait de la configuration appropriée de reporter le contrôle de l'application de la vôtre.

Flup est une autre façon de courir avec WSGI pour n'importe quel serveur web qui peuvent parler FCGI, SCGI ou de l'AJP. De mon expérience, seulement FCGI fonctionne vraiment, et il peut être utilisé dans Apache soit par l'intermédiaire de mod_fastcgi ou si vous pouvez courir un distinct Python démon avec mod_proxy_fcgi.

WSGI est un protocole un peu comme CGI, qui définit un ensemble de règles sur la manière d'serveur web et le code Python peuvent interagir, il est défini comme Pep333. Elle permet que de nombreux serveurs web peuvent utiliser beaucoup de différents cadres et des applications utilisant le même protocole d'application. Ceci est très bénéfique et qui le rend si utile.

Answer 4

Si vous êtes pas clair sur tous les termes dans cet espace et laisse le visage, c’est un acronyme-laden confus, il y a aussi un lecteur bon fond sous la forme d’un python officiel HOWTO qui traite de CGI et FastCGI vs WSGI et ainsi de suite : http://docs.python.org/howto/ Webservers.html

Answer 5

C'est une simple couche d'abstraction pour Python, qui s'apparente à ce que la Servlet spec est de Java. Alors que CGI est vraiment faible niveau et juste décharges des trucs dans le processus de l'environnement et des normes en/hors, les deux spécifications modèle de la demande et la réponse http en tant que constructions dans la langue. Mon impression est cependant qu'en Python les gens n'ont pas tout à fait réglé sur de facto implémentations de sorte que vous avez un mélange des implémentations de référence, et les autres services publics-type de bibliothèques qui fournissent d'autres choses avec WSGI de soutien (par exemple, Coller). Bien sûr je peux me tromper, je suis un nouveau venu à Python. Le "script web" communauté au problème à partir d'une direction différente (hébergement mutualisé, CGI héritage, le privilège de la séparation des préoccupations) que Java les gens ont le luxe de partir avec (l'exécution d'une seule entreprise, le récipient dans un environnement dédié à l'encontre compilé statiquement et déployé code).