问题:Python Web框架,WSGI和CGI如何结合在一起

我有一个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.pyCherryPy),该怎么办?如何安装WSGI支持?

I have a Bluehost account where I can run Python scripts as CGI. I guess it’s the simplest CGI, because to run I have to define the following in .htaccess:

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

Now, whenever I look up web programming with Python, I hear a lot about WSGI and how most frameworks use it. But I just don’t understand how it all fits together, especially when my web server is given (Apache running at a host’s machine) and not something I can really play with (except defining .htaccess commands).

How are WSGI, CGI, and the frameworks all connected? What do I need to know, install, and do if I want to run a web framework (say web.py or CherryPy) on my basic CGI configuration? How to install WSGI support?


回答 0

WSGI,CGI和框架如何连接?

Apache侦听端口80。它获取HTTP请求。它解析请求以找到一种响应方式。Apache有很多可供选择的响应方式。一种响应方式是使用CGI运行脚本。另一种响应方式是简单地提供文件。

对于CGI,Apache准备一个环境并通过CGI协议调用脚本。这是标准的Unix Fork / Exec情况-CGI子进程继承了包括套接字和标准输出的OS环境。CGI子进程编写一个响应,该响应可以返回到Apache。Apache将此响应发送到浏览器。

CGI是原始且令人讨厌的。主要是因为它为每个请求派生一个子流程,并且该子流程必须退出或关闭stdout和stderr来表示响应结束。

WSGI是基于CGI设计模式的接口。它不一定是CGI,也不必为每个请求派生一个子进程。可以是CGI,但不一定如此。

WSGI以几种重要方式添加到CGI设计模式中。它为您解析HTTP请求标头,并将其添加到环境中。它提供任何面向POST的输入,作为环境中的类似文件的对象。它还为您提供了可以制定响应的功能,从而使您免于许多格式设置细节。

如果要在基本CGI配置上运行Web框架(例如web.py或cherrypy),我需要知道/安装/做什么?

回想一下,分叉子过程很昂贵。有两种方法可以解决此问题。

  1. 在Apache中嵌入mod_wsgimod_python嵌入Python;没有分叉的过程。Apache直接运行Django应用程序。

  2. 守护程序, mod_wsgimod_fastcgi允许Apache使用WSGI协议与单独的守护程序(或“长时间运行的进程”)进行交互。您启动长期运行的Django进程,然后配置Apache的mod_fastcgi与该进程进行通信。

请注意,它mod_wsgi可以在两种模式下工作:嵌入式或守护程序。

当您阅读mod_fastcgi时,您会发现Django使用flup从mod_fastcgi提供的信息创建与WSGI兼容的接口。管道的工作原理是这样的。

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

Django为各种接口提供了多个“ django.core.handlers”。

对于mod_fastcgi,Django提供了一个manage.py runfcgi集成FLUP和处理程序的。

对于mod_wsgi,有一个核心处理程序。

如何安装WSGI支持?

请遵循以下说明。

https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki

对于背景,请参阅此

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

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.

  1. Embedded mod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.

  2. 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


回答 1

我认为Florian的答案回答了您有关“ WSGI是什么”的部分问题,特别是如果您阅读了PEP

至于您即将提出的问题:

WSGI,CGI,FastCGI等都是Web服务器运行代码并传递产生的动态内容的协议。与此相比,静态Web服务基本上是将纯HTML文件原样发送到客户端的静态Web服务。

CGI,FastCGI和SCGI与语言无关。您可以用Perl,Python,C,bash等编写CGI脚本。CGI 根据URL 定义将调用哪个可执行文件,以及如何调用它:参数和环境。它还定义了可执行文件完成后应如何将返回值传递回Web服务器。这些变化基本上是优化的,以便能够处理更多请求,减少延迟等。基本概念是相同的。

WSGI仅适用于Python。定义了标准功能签名,而不是语言无关协议:

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']

那是一个完整的(如果有限制的话)WSGI应用程序。具有WSGI支持的Web服务器(例如具有mod_wsgi的Apache)可以在请求到达时调用此功能。

之所以如此出色,是因为我们可以避免从HTTP GET / POST转换为CGI再转换为Python的繁琐步骤,并在退出过程中再次返回。这是一种更加直接,干净和有效的链接。

如果需要对请求进行的所有操作都是函数调用,那么使长时间运行的框架在Web服务器后运行也变得更加容易。使用普通的CGI,您必须为每个单独的请求启动整个框架

要获得WSGI支持,您需要安装WSGI模块(如mod_wsgi),或使用带有WSGI嵌入的Web服务器(如CherryPy)。如果两者都不可行,则可以使用PEP中提供的CGI-WSGI桥。

I think Florian’s answer answers the part of your question about “what is WSGI”, especially if you read the PEP.

As for the questions you pose towards the end:

WSGI, CGI, FastCGI etc. are all protocols for a web server to run code, and deliver the dynamic content that is produced. Compare this to static web serving, where a plain HTML file is basically delivered as is to the client.

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.


回答 2

如Pep333所示,您可以在CGI上运行WSGI。但是,每次有一个请求时,都会启动一个新的Python解释器,并且需要构建整个上下文(数据库连接等),这都需要时间。

如果要运行WSGI,最好的方法是主机安装mod_wsgi并进行适当的配置以将控制权交给您的应用程序。

对于任何会说FCGISCGI或AJP的Web服务器,Flup是与WSGI一起运行的另一种方式。根据我的经验,只有FCGI确实有效,并且可以通过mod_fastcgi在Apache中使用它,或者可以通过mod_proxy_fcgi运行单独的Python守护程序。

WSGI是与CGI非常相似的协议,它定义了一组Web服务器和Python代码如何交互的规则,其定义为Pep333。这使得许多不同的Web服务器可以使用同一应用程序协议来使用许多不同的框架和应用程序。这是非常有益的,并使其非常有用。

You can run WSGI over CGI as Pep333 demonstrates as an example. However every time there is a request a new Python interpreter is started and the whole context (database connections, etc.) needs to be build which all take time.

The best if you want to run WSGI would be if your host would install mod_wsgi and made an appropriate configuration to defer control to an application of yours.

Flup is another way to run with WSGI for any webserver that can speak FCGI, SCGI or AJP. From my experience only FCGI really works, and it can be used in Apache either via mod_fastcgi or if you can run a separate Python daemon with mod_proxy_fcgi.

WSGI is a protocol much like CGI, which defines a set of rules how webserver and Python code can interact, it is defined as Pep333. It makes it possible that many different webservers can use many different frameworks and applications using the same application protocol. This is very beneficial and makes it so useful.


回答 3

如果您不清楚这个领域中的所有术语,并且让我们直面它,这是一个令人困惑的首字母缩写词,那么还有一个很好的背景阅读器,形式为官方python HOWTO,其中讨论了CGI,FastCGI,WSGI等。上:http : //docs.python.org/howto/webservers.html

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


回答 4

这是用于Python的简单抽象层,类似于Servlet规范用于Java。尽管CGI确实是低级的,只是将内容转储到流程环境和标准输入/输出中,但是以上两个规范将http请求和响应建模为该语言的构造。但是,我的印象是,在Python中,人们还不太习惯实际的实现,因此您混合使用了参考实现和其他提供WSGI支持(例如Paste)的实用程序类型的库。当然,我可能是错的,我是Python的新手。“网络脚本”社区正从不同的方向提出问题(共享托管,CGI旧版,

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).


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。