Python 什么是简单英语的 WSGI 和 CGI?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/4929626/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are WSGI and CGI in plain English?
提问by Blankman
Every time I read either WSGI or CGI I cringe. I've tried reading on it before but nothing really has stuck.
每次我阅读 WSGI 或 CGI 时都会感到畏缩。我以前试过阅读它,但没有真正卡住。
What is it really in plain English?
什么是简单的英语?
Does it just pipe requests to a terminal and redirect the output?
它是否只是通过管道将请求发送到终端并重定向输出?
采纳答案by Ignacio Vazquez-Abrams
WSGI runs the Python interpreter on web server start, either as part of the web server process (embedded mode) or as a separate process (daemon mode), and loads the script into it. Each request results in a specific function in the script being called, with the request environment passed as arguments to the function.
WSGI 在 web 服务器启动时运行 Python 解释器,作为 web 服务器进程的一部分(嵌入式模式)或作为一个单独的进程(守护进程模式),并将脚本加载到其中。每个请求都会导致脚本中的一个特定函数被调用,请求环境作为参数传递给函数。
CGI runs the script as a separate process each request and uses environment variables, stdin, and stdout to "communicate" with it.
CGI 将脚本作为每个请求的单独进程运行,并使用环境变量、stdin 和 stdout 与其“通信”。
回答by Wooble
Both CGI and WSGI define standard interfaces that programs can use to handle web requests. The CGI interface is at a lower level than WSGI, and involves the server setting up environment variables containing the data from the HTTP request, with the program returning something formatted pretty much like a bare HTTP server response.
CGI 和 WSGI 都定义了程序可以用来处理 Web 请求的标准接口。CGI 接口处于比 WSGI 更低的级别,并且涉及服务器设置包含来自 HTTP 请求的数据的环境变量,程序返回格式非常类似于裸 HTTP 服务器响应的内容。
WSGI, on the other hand, is a Python-specific, slightly higher-level interface that allows programmers to write applications that are server-agnostic and which can be wrapped in other WSGI applications (middleware).
另一方面,WSGI 是特定于 Python 的、级别稍高的接口,允许程序员编写与服务器无关的应用程序,并且可以包装在其他 WSGI 应用程序(中间件)中。
回答by Mark Henwood
From a totally step-back point of view, Blankman, here is my "Intro Page" for Web Services Gateway Interface:
从完全退一步的角度来看,Blankman,这是我的 Web 服务网关接口的“介绍页面”:
PART ONE: WEB SERVERS
第 1 部分:网络服务器
Web servers serve up responses. They sit around, waiting patiently, and then with no warning at all, suddenly:
Web 服务器提供响应。他们坐在一旁,耐心等待,然后毫无征兆地,突然:
- a client process sends a request. The client process could be a web server, a bot, a mobile app, whatever. It is simply "the client"
- the web server receives this request
- deliberate mumblevarious things happen (see below)
- The web server sends back something to the client
- web server sits around again
- 客户端进程发送请求。客户端进程可以是 Web 服务器、机器人、移动应用程序等。简直就是“客户”
- Web 服务器收到此请求
- 故意嘟囔各种事情发生(见下文)
- Web 服务器向客户端发送回一些信息
- 网络服务器再次出现
Web servers (at least, the better ones) are very VERY good at this. They scale up and down processing depending on demand, they reliably hold conversations with the flakiest of clients over really cruddy networks and we never really have to worry about it. They just keep on serving.
Web 服务器(至少是更好的服务器)在这方面非常擅长。他们根据需求扩大和缩小处理规模,他们通过非常简陋的网络可靠地与最脆弱的客户进行对话,我们从来没有真正担心过。他们只是继续服务。
This is my point: web servers are just that: servers. They know nothing about content, nothing about users, nothing in fact other than how to wait a lot and reply reliably.
这是我的观点:Web 服务器就是:服务器。他们对内容一无所知,对用户一无所知,实际上除了如何等待并可靠回复之外一无所知。
Your choice of web server should reflect your delivery preference, not your software. Your web server should be in charge of serving, not processing or logical stuff.
您选择的 Web 服务器应反映您的交付偏好,而不是您的软件。您的 Web 服务器应该负责服务,而不是处理或逻辑内容。
PART TWO: (PYTHON) SOFTWARE
第二部分:(Python)软件
Software does not sit around. Software only exists at execution time. Software is not terribly accommodating when it comes to unexpected changes in its environment (files not being where it expects, parameters being renamed etc). Although optimisation should be a central tenet of your design (of course), software itself does not optimise. Developers optimise. Software executes. Software does all the stuff in the 'deliberate mumble' section above. Could be anything.
软件不会闲着。软件只存在于执行时。当涉及环境中的意外变化(文件不在预期位置,参数被重命名等)时,软件并不是非常适应。尽管优化应该是您设计的核心原则(当然),但软件本身并不会进行优化。开发人员优化。软件执行。软件会完成上面“故意嘟嘟嘟”部分中的所有内容。可以是任何东西。
Your choice or design of software should reflect your application, your choice of functionality, and not your choice of web server.
您对软件的选择或设计应反映您的应用程序、您对功能的选择,而不是您对 Web 服务器的选择。
This is where the traditional method of "compiling in" languages to web servers becomes painful. You end up putting code in your application to cope with the physical server environment or, at least, being forced to choose an appropriate 'wrapper' library to include at runtime, to give the illusion of uniformity across web servers.
这就是将语言“编译”到 Web 服务器的传统方法变得痛苦的地方。您最终将代码放入应用程序中以应对物理服务器环境,或者至少被迫选择一个适当的“包装器”库以包含在运行时,以提供跨 Web 服务器的统一错觉。
SO WHAT IS WSGI?
那么什么是 WSGI?
So, at last, what is WSGI? WSGI is a set of rules, written in two halves. They are written in such a way that they can be integrated into any environment that welcomes integration.
那么,最后,什么是 WSGI?WSGI 是一套规则,分为两部分。它们的编写方式使得它们可以集成到任何欢迎集成的环境中。
The first part, written for the web server side, says "OK, if you want to deal with a WSGI application, here's how the software will be thinking when it loads. Here are the things you must make available to the application, and here is the interface (layout) that you can expect every application to have. Moreover, if anything goes wrong, here's how the app will be thinking and how you can expect it to behave."
第一部分是为 Web 服务器端编写的,它说“好吧,如果你想处理 WSGI 应用程序,这里是软件加载时的思考方式。这里是你必须提供给应用程序的东西,这里是您可以期望每个应用程序具有的界面(布局)。此外,如果出现任何问题,这就是应用程序的思考方式以及您可以期望它的行为方式。”
The second part, written for the Python application software, says "OK, if you want to deal with a WSGI server, here's how the server will be thinking when it contacts you. Here are the things you must make available to the server, and here is the interface (layout) that you can expect every server to have. Moreover, if anything goes wrong, here's how you should behave and here's what you should tell the server."
第二部分是为 Python 应用程序软件编写的,它说“好吧,如果你想处理一个 WSGI 服务器,这里是服务器联系你时的想法。这里是你必须提供给服务器的东西,以及这是您可以期望每台服务器都具有的界面(布局)。此外,如果出现任何问题,这就是您的行为方式,以及您应该告诉服务器的内容。”
So there you have it - servers will be servers and software will be software, and here's a way they can get along just great without one having to make any allowances for the specifics of the other. This is WSGI.
所以你有它 - 服务器将是服务器,软件将是软件,这是一种他们可以相处得很好的方式,而不必考虑其他人的细节。这是 WSGI。
mod_wsgi, on the other hand, is a plugin for Apache that lets it talk to WSGI-compliant software, in other words, mod_wsgi is an implementation- in Apache - of the rules of part one of the rulebook above.
另一方面,mod_wsgi 是 Apache 的一个插件,可以让它与符合 WSGI 的软件进行通信,换句话说,mod_wsgi 是上述规则手册第一部分规则的一种实现- 在 Apache 中。
As for CGI.... ask someone else :-)
至于CGI....问别人:-)
回答by Richard Boardman
If you are unclear on all the terms in this space, and let's face it, it's a confusing acronym-laden one, there's also a good background reader in the form of an official python HOWTOwhich discusses CGI vs. FastCGI vs. WSGI and so on. I wish I'd read it first.
如果您对这个领域的所有术语都不清楚,让我们面对现实,这是一个令人困惑的首字母缩略词,还有一个很好的背景阅读器,以官方 Python HOWTO 的形式讨论 CGI vs. FastCGI vs. WSGI 等等在。我希望我先阅读它。

