Python Web 框架、WSGI 和 CGI 如何结合在一起

发布于 2024-07-07 08:45:21 字数 740 浏览 6 评论 0原文

我有一个 Bluehost 帐户，我可以在其中将 Python 脚本作为 CGI 运行。我想这是最简单的 CGI，因为要运行我必须在 .htaccess 中定义以下内容：

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

现在，每当我使用 Python 查找 Web 编程时，我都会听到很多有关 WSGI 以及大多数框架如何使用它的信息。但我只是不明白这一切是如何组合在一起的，尤其是当我的网络服务器（Apache 在主机上运行）而不是我真正可以使用的东西时（除了定义 .htaccess 命令）。

WSGI、CGI 和框架是如何连接的？如果我想运行 Web 框架（例如 web.py 或 < a href="http://en.wikipedia.org/wiki/CherryPy" rel="noreferrer">CherryPy) 在我的基本 CGI 配置上？如何安装 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?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

舞袖。长 2024-07-14 08:45:21

WSGI、CGI 和框架如何连接？

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

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

CGI 既原始又烦人。主要是因为它为每个请求分叉一个子进程，并且子进程必须退出或关闭 stdout 和 stderr 以表示响应结束。

WSGI 是一个基于CGI 设计模式的接口。它不一定是 CGI——它不必为每个请求创建一个子进程。它可以是 CGI，但不一定是。

WSGI 以几个重要的方式添加到 CGI 设计模式中。它为您解析 HTTP 请求标头并将其添加到环境中。它在环境中将任何面向 POST 的输入作为类似文件的对象提供。它还为您提供了一个可以制定响应的函数，从而使您免于处理大量格式细节。

如果我想在基本 CGI 配置上运行 Web 框架（例如 web.py 或cherrypy），我需要了解/安装/做什么？

回想一下，分叉子进程的成本很高。有两种方法可以解决这个问题。

嵌入式 mod_wsgi 或 mod_python 将 Python 嵌入到 Apache 中；没有进程被分叉。 Apache 直接运行 Django 应用程序。
守护进程 mod_wsgi 或 mod_fastcgi 允许 Apache 使用 WSGI 协议与单独的守护进程（或“长时间运行的进程”）进行交互。您启动长时间运行的 Django 进程，然后配置 Apache 的 mod_fastcgi 来与此进程通信。

请注意，mod_wsgi 可以在任一模式下工作：嵌入式或守护程序。

当您阅读 mod_fastcgi 时，您会发现 Django 使用 flup 创建 WSGI-从mod_fastcgi提供的信息来看兼容接口。管道的工作原理如下。

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

Django 有几个用于各种接口的“django.core.handlers”。

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

对于 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.

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

回复收藏 0 原文

花落人断肠 2024-07-14 08:45:21

我认为 Florian 的回答回答了关于“什么是 WSGI”的问题的一部分，特别是如果您阅读了PEP 。

至于您在最后提出的问题：

WSGI、CGI、FastCGI 等都是 Web 服务器运行代码并交付所生成的动态内容的协议。将此与静态 Web 服务进行比较，静态 Web 服务基本上将纯 HTML 文件按原样传递给客户端。

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.

回复收藏 0 原文

刘备忘录 2024-07-14 08:45:21

您可以按照 Pep333 的演示通过 CGI 运行 WSGI 举个例子。然而，每次有请求时，都会启动一个新的 Python 解释器，并且需要构建整个上下文（数据库连接等），这一切都需要时间。

如果您想运行 WSGI，最好的办法是您的主机安装 mod_wsgi 并进行适当的配置配置将控制权推迟到您的应用程序。

Flup 是为任何可以说话的网络服务器运行 WSGI 的另一种方式 FCGI, SCGI 或 AJP。根据我的经验，只有 FCGI 真正有效，并且可以通过 mod_fastcgi 或者如果您可以使用 mod_proxy_fcgi 运行单独的 Python 守护程序。

WSGI 是一个很像 CGI 的协议，它定义了一组 Web 服务器和 Python 代码如何交互的规则，它被定义为 < a href="http://www.python.org/dev/peps/pep-0333" rel="noreferrer">Pep333。它使得许多不同的网络服务器可以使用许多不同的框架和使用相同应用程序协议的应用程序。这是非常有益的，并且非常有用。

回复收藏 0 原文

水染的天色ゝ 2024-07-14 08:45:21

如果你不清楚这个领域的所有术语，那么让我们面对现实吧，这是一个令人困惑的缩写词，还有一个很好的背景阅读器，以官方 python HOWTO 的形式，讨论了 CGI 与 FastCGI 与 WSGI 等等上：http://docs.python.org/howto/webservers.html

回复收藏 0 原文

桃扇骨 2024-07-14 08:45:21

它是 Python 的一个简单抽象层，类似于 Java 的 Servlet 规范。尽管 CGI 确实是低级的，只是将内容转储到进程环境和标准输入/输出中，但上述两个规范将 http 请求和响应建模为语言中的构造。然而，我的印象是，在 Python 中，人们还没有完全确定实际的实现，因此您有参考实现和其他实用程序类型库的混合，这些库提供了 WSGI 支持的其他功能（例如粘贴）。当然我可能是错的，我是Python的新手。 “Web 脚本”社区从不同的方向（共享托管、CGI 遗留、特权分离问题）来解决这个问题，而 Java 人员则从不同的角度（在专用环境中运行单个企业容器来对抗静态编译和部署）代码）。

回复收藏 0 原文

~没有更多了~