我有一个Bluehost帐户，我可以在其中将 Python 脚本作为 CGI 运行。我想这是最简单的 CGI，因为要运行，我必须在 中定义以下内容.htaccess：
Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py
现在，每当我使用 Python 进行 Web 编程时，我都会听到很多关于 WSGI 以及大多数框架如何使用它的信息。但是我只是不明白这一切是如何结合在一起的，尤其是当我的 Web 服务器被提供时（Apache 在主机的机器上运行）而不是我真正可以玩的东西（除了定义.htaccess命令）。
WSGI、CGI 和框架是如何连接的？如果我想在我的基本 CGI 配置上运行 Web 框架（例如web.py或CherryPy ），我需要知道、安装和做什么？如何安装 WSGI 支持？
How WSGI, CGI, and the frameworks are all connected?
Apache listens on port 80. It gets an HTTP request. It parses the request to find a way to respond. Apache has a LOT of choices for responding. One way to respond is to use CGI to run a script. Another way to respond is to simply serve a file.
In the case of CGI, Apache prepares an environment and invokes the script through the CGI protocol. This is a standard Unix Fork/Exec situation -- the CGI subprocess inherits an OS environment including the socket and stdout. The CGI subprocess writes a response, which goes back to Apache; Apache sends this response to the browser.
CGI is primitive and annoying. Mostly because it forks a subprocess for every request, and subprocess must exit or close stdout and stderr to signify end of response.
WSGI is an interface that is based on the CGI design pattern. It is not necessarily CGI -- it does not have to fork a subprocess for each request. It can be CGI, but it doesn't have to be.
WSGI adds to the CGI design pattern in several important ways. It parses the HTTP Request Headers for you and adds these to the environment. It supplies any POST-oriented input as a file-like object in the environment. It also provides you a function that will formulate the response, saving you from a lot of formatting details.
What do I need to know / install / do if I want to run a web framework (say web.py or cherrypy) on my basic CGI configuration?
Recall that forking a subprocess is expensive. There are two ways to work around this.
Embedded mod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.
Daemon mod_wsgi or mod_fastcgi allows Apache to interact with a separate daemon (or "long-running process"), using the WSGI protocol. You start your long-running Django process, then you configure Apache's mod_fastcgi to communicate with this process.
Note that mod_wsgi can work in either mode: embedded or daemon.
When you read up on mod_fastcgi, you'll see that Django uses flup to create a WSGI-compatible interface from the information provided by mod_fastcgi. The pipeline works like this.
Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)
Django has several "django.core.handlers" for the various interfaces.
For mod_fastcgi, Django provides a manage.py runfcgi that integrates FLUP and the handler.
For mod_wsgi, there's a core handler for this.
How to install WSGI support?
Follow these instructions.
https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki
For background see this
http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index
我认为Florian 的回答回答了您关于“什么是 WSGI”的问题，特别是如果您阅读了 PEP。
至于你最后提出的问题：
WSGI、CGI、FastCGI 等都是 Web 服务器运行代码并传递生成的动态内容的协议。将此与静态 Web 服务进行比较，其中纯 HTML 文件基本上按原样交付给客户端。
CGI, FastCGI and SCGI are language agnostic. You can write CGI scripts in Perl, Python, C, bash, whatever. CGI defines which executable will be called, based on the URL, and how it will be called: the arguments and environment. It also defines how the return value should be passed back to the web server once your executable is finished. The variations are basically optimisations to be able to handle more requests, reduce latency and so on; the basic concept is the same.
WSGI is Python only. Rather than a language agnostic protocol, a standard function signature is defined:
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']
That is a complete (if limited) WSGI application. A web server with WSGI support (such as Apache with mod_wsgi) can invoke this function whenever a request arrives.
The reason this is so great is that we can avoid the messy step of converting from a HTTP GET/POST to CGI to Python, and back again on the way out. It's a much more direct, clean and efficient linkage.
It also makes it much easier to have long-running frameworks running behind web servers, if all that needs to be done for a request is a function call. With plain CGI, you'd have to start your whole framework up for each individual request.
To have WSGI support, you'll need to have installed a WSGI module (like mod_wsgi), or use a web server with WSGI baked in (like CherryPy). If neither of those are possible, you could use the CGI-WSGI bridge given in the PEP.
您可以在 CGI 上运行 WSGI，如 Pep333 演示的示例。然而，每次有请求时，都会启动一个新的 Python 解释器，并且需要构建整个上下文（数据库连接等），这都需要时间。
如果您想运行 WSGI，最好的办法是您的主机安装mod_wsgi并进行适当的配置以将控制权交给您的应用程序。
Flup是另一种使用 WSGI 运行任何可以说FCGI、SCGI或 AJP 的网络服务器的方式。根据我的经验，只有 FCGI 真正有效，并且可以通过mod_fastcgi或者您可以使用mod_proxy_fcgi运行单独的 Python 守护程序在 Apache 中使用它。
WSGI是一个很像 CGI 的协议，它定义了一组规则如何 webserver 和 Python 代码可以交互，它被定义为Pep333。这使得许多不同的网络服务器可以使用许多不同的框架和应用程序使用相同的应用程序协议成为可能。这是非常有益的，并且非常有用。
If you are unclear on all the terms in this space, and lets face it, its a confusing acronym-laden one, there's also a good background reader in the form of an official python HOWTO which discusses CGI vs. FastCGI vs. WSGI and so on: http://docs.python.org/howto/webservers.html
It's a simple abstraction layer for Python, akin to what the Servlet spec is for Java. Whereas CGI is really low level and just dumps stuff into the process environment and standard in/out, the above two specs model the http request and response as constructs in the language. My impression however is that in Python folks have not quite settled on de-facto implementations so you have a mix of reference implementations, and other utility-type libraries that provide other things along with WSGI support (e.g. Paste). Of course I could be wrong, I'm a newcomer to Python. The "web scripting" community is coming at the problem from a different direction (shared hosting, CGI legacy, privilege separation concerns) than Java folks had the luxury of starting with (running a single enterprise container in a dedicated environment against statically compiled and deployed code).