WSGI ejecuta el intérprete de Python en el inicio del servidor web, ya sea como parte del proceso del servidor web (modo incrustado) o como un proceso separado (modo daemon), y carga el script en él. Cada solicitud da como resultado una función específica en el script que se llama, con el entorno de solicitud pasado como argumentos a la función.
CGI ejecuta el script como un proceso separado para cada solicitud y utiliza variables de entorno, stdin y stdout para "comunicarse" con él.
WSGI! = Mod_wsgi. Su idioma sugiere que se refiere a mod_wsgi, que es una implementación de WSGI. WSGI en sí es simplemente una especificación y se puede implementar de muchas maneras diferentes, incluso por encima de CGI.
Graham Dumpleton
@Graham: ¿Estás diciendo que no hay otros contenedores WSGI que admitan la ejecución de aplicaciones WSGI en esos modos?
Ignacio Vazquez-Abrams
3
Técnicamente, se podría decir que hay variaciones más sutiles que solo esas dos, al menos en cuanto a cómo se inician los procesos o cómo se activa el código dentro de un sistema integrado. Así que uno debe tener cuidado al generalizar las cosas en esas dos categorías. En un nivel bruto, puedes decir lo que tienes, pero hay mucho más que eso si quieres profundizar en él.
Graham Dumpleton
1
@GrahamDumpleton, por curiosidad, ¿le importaría explicar cómo se puede implementar WSGI sobre CGI?
Desde un punto de vista totalmente retroactivo, Blankman, aquí está mi "Página de introducción" para la interfaz de puerta de enlace de servicios web:
PRIMERA PARTE: SERVIDORES WEB
Los servidores web ofrecen respuestas. Se sientan a esperar pacientemente y luego, sin previo aviso, de repente:
Un proceso de cliente envía una solicitud. El proceso del cliente podría ser un servidor web, un bot, una aplicación móvil, lo que sea. Es simplemente "el cliente"
el servidor web recibe esta solicitud
murmullo deliberado suceden varias cosas (ver más abajo)
El servidor web devuelve algo al cliente.
el servidor web se sienta de nuevo
Los servidores web (al menos, los mejores) son MUY buenos en esto. Escalan y reducen el procesamiento según la demanda, mantienen conversaciones confiables con los clientes más descarados a través de redes realmente difíciles y realmente nunca tenemos que preocuparnos por eso. Simplemente siguen sirviendo.
Este es mi punto: los servidores web son solo eso: servidores. No saben nada sobre contenido, nada sobre usuarios, nada más que esperar y responder de manera confiable.
Su elección del servidor web debe reflejar su preferencia de entrega, no su software. Su servidor web debe estar a cargo de servir, no procesar o cosas lógicas.
SEGUNDA PARTE: SOFTWARE (PYTHON)
El software no se sienta. El software solo existe en el momento de la ejecución. El software no es muy flexible cuando se trata de cambios inesperados en su entorno (los archivos no están donde se espera, los parámetros se renombran, etc.). Aunque la optimización debería ser un principio central de su diseño (por supuesto), el software en sí no se optimiza. Los desarrolladores optimizan. El software se ejecuta. El software hace todas las cosas en la sección de "murmullo deliberado" anterior. Podría ser cualquier cosa.
Su elección o diseño de software debe reflejar su aplicación, su elección de funcionalidad y no su elección de servidor web.
Aquí es donde el método tradicional de "compilar" idiomas en servidores web se vuelve doloroso. Termina poniendo código en su aplicación para hacer frente al entorno del servidor físico o, al menos, se ve obligado a elegir una biblioteca 'wrapper' apropiada para incluir en el tiempo de ejecución, para dar la ilusión de uniformidad en los servidores web.
Entonces, ¿qué es WSGI?
Entonces, por fin, ¿qué es WSGI? WSGI es un conjunto de reglas , escrito en dos mitades. Están escritos de tal manera que se pueden integrar en cualquier entorno que agradezca la integración.
La primera parte, escrita para el lado del servidor web, dice "OK, si desea tratar con una aplicación WSGI, así es como el software estará pensando cuando se cargue. Estas son las cosas que debe poner a disposición de la aplicación, y aquí es la interfaz (diseño) que puede esperar que tenga cada aplicación. Además, si algo sale mal, así es como la aplicación estará pensando y cómo puede esperar que se comporte ".
La segunda parte, escrita para el software de la aplicación Python, dice "OK, si quieres tratar con un servidor WSGI, así es como el servidor estará pensando cuando te contacte. Estas son las cosas que debes poner a disposición del servidor, y aquí está la interfaz (diseño) que puede esperar que tenga cada servidor. Además, si algo sale mal, así es como debe comportarse y esto es lo que debe decirle al servidor ".
Así que ahí lo tienes: los servidores serán servidores y el software será software, y aquí hay una forma en que pueden llevarse bien sin que uno tenga que tener en cuenta los detalles del otro. Esto es WSGI.
mod_wsgi, por otro lado, es un complemento para Apache que le permite hablar con software compatible con WSGI, en otras palabras, mod_wsgi es una implementación , en Apache, de las reglas de la primera parte del libro de reglas anterior.
En lugar de dejar que esta respuesta termine con "preguntar a alguien más", deseo que alguien edite esta respuesta para incluir CGI de la misma manera.
Bruno Bronosky
1
'los servidores serán servidores y el software será software' - 'los servidores son de Marte y el software es de Venus' :)
Rahul
22
Si no está claro en todos los términos en este espacio, y seamos sinceros, es un acrónimo confuso, también hay un buen lector de antecedentes en forma de un COMO oficial de Python que discute CGI vs. FastCGI vs. WSGI y así en. Desearía haberlo leído primero.
Tanto CGI como WSGI definen interfaces estándar que los programas pueden usar para manejar solicitudes web. La interfaz CGI está en un nivel más bajo que WSGI e involucra al servidor configurando variables de entorno que contienen los datos de la solicitud HTTP, con el programa devolviendo algo formateado más o menos como una respuesta de servidor HTTP.
WSGI, por otro lado, es una interfaz específica de Python, de nivel ligeramente superior que permite a los programadores escribir aplicaciones que son independientes del servidor y que pueden incluirse en otras aplicaciones WSGI (middleware).
Respuestas:
WSGI ejecuta el intérprete de Python en el inicio del servidor web, ya sea como parte del proceso del servidor web (modo incrustado) o como un proceso separado (modo daemon), y carga el script en él. Cada solicitud da como resultado una función específica en el script que se llama, con el entorno de solicitud pasado como argumentos a la función.
CGI ejecuta el script como un proceso separado para cada solicitud y utiliza variables de entorno, stdin y stdout para "comunicarse" con él.
fuente
Desde un punto de vista totalmente retroactivo, Blankman, aquí está mi "Página de introducción" para la interfaz de puerta de enlace de servicios web:
PRIMERA PARTE: SERVIDORES WEB
Los servidores web ofrecen respuestas. Se sientan a esperar pacientemente y luego, sin previo aviso, de repente:
Los servidores web (al menos, los mejores) son MUY buenos en esto. Escalan y reducen el procesamiento según la demanda, mantienen conversaciones confiables con los clientes más descarados a través de redes realmente difíciles y realmente nunca tenemos que preocuparnos por eso. Simplemente siguen sirviendo.
Este es mi punto: los servidores web son solo eso: servidores. No saben nada sobre contenido, nada sobre usuarios, nada más que esperar y responder de manera confiable.
Su elección del servidor web debe reflejar su preferencia de entrega, no su software. Su servidor web debe estar a cargo de servir, no procesar o cosas lógicas.
SEGUNDA PARTE: SOFTWARE (PYTHON)
El software no se sienta. El software solo existe en el momento de la ejecución. El software no es muy flexible cuando se trata de cambios inesperados en su entorno (los archivos no están donde se espera, los parámetros se renombran, etc.). Aunque la optimización debería ser un principio central de su diseño (por supuesto), el software en sí no se optimiza. Los desarrolladores optimizan. El software se ejecuta. El software hace todas las cosas en la sección de "murmullo deliberado" anterior. Podría ser cualquier cosa.
Su elección o diseño de software debe reflejar su aplicación, su elección de funcionalidad y no su elección de servidor web.
Aquí es donde el método tradicional de "compilar" idiomas en servidores web se vuelve doloroso. Termina poniendo código en su aplicación para hacer frente al entorno del servidor físico o, al menos, se ve obligado a elegir una biblioteca 'wrapper' apropiada para incluir en el tiempo de ejecución, para dar la ilusión de uniformidad en los servidores web.
Entonces, ¿qué es WSGI?
Entonces, por fin, ¿qué es WSGI? WSGI es un conjunto de reglas , escrito en dos mitades. Están escritos de tal manera que se pueden integrar en cualquier entorno que agradezca la integración.
La primera parte, escrita para el lado del servidor web, dice "OK, si desea tratar con una aplicación WSGI, así es como el software estará pensando cuando se cargue. Estas son las cosas que debe poner a disposición de la aplicación, y aquí es la interfaz (diseño) que puede esperar que tenga cada aplicación. Además, si algo sale mal, así es como la aplicación estará pensando y cómo puede esperar que se comporte ".
La segunda parte, escrita para el software de la aplicación Python, dice "OK, si quieres tratar con un servidor WSGI, así es como el servidor estará pensando cuando te contacte. Estas son las cosas que debes poner a disposición del servidor, y aquí está la interfaz (diseño) que puede esperar que tenga cada servidor. Además, si algo sale mal, así es como debe comportarse y esto es lo que debe decirle al servidor ".
Así que ahí lo tienes: los servidores serán servidores y el software será software, y aquí hay una forma en que pueden llevarse bien sin que uno tenga que tener en cuenta los detalles del otro. Esto es WSGI.
mod_wsgi, por otro lado, es un complemento para Apache que le permite hablar con software compatible con WSGI, en otras palabras, mod_wsgi es una implementación , en Apache, de las reglas de la primera parte del libro de reglas anterior.
En cuanto a CGI ... pregúntale a alguien más :-)
fuente
Si no está claro en todos los términos en este espacio, y seamos sinceros, es un acrónimo confuso, también hay un buen lector de antecedentes en forma de un COMO oficial de Python que discute CGI vs. FastCGI vs. WSGI y así en. Desearía haberlo leído primero.
fuente
Tanto CGI como WSGI definen interfaces estándar que los programas pueden usar para manejar solicitudes web. La interfaz CGI está en un nivel más bajo que WSGI e involucra al servidor configurando variables de entorno que contienen los datos de la solicitud HTTP, con el programa devolviendo algo formateado más o menos como una respuesta de servidor HTTP.
WSGI, por otro lado, es una interfaz específica de Python, de nivel ligeramente superior que permite a los programadores escribir aplicaciones que son independientes del servidor y que pueden incluirse en otras aplicaciones WSGI (middleware).
fuente