知识问答

普通英语的WSGI和CGI是什么？

内容 隐藏
问题：普通英语的WSGI和CGI是什么？
回答 0
回答 1
回答 2
回答 3

问题：普通英语的WSGI和CGI是什么？

每次阅读WSGI或CGI时，我都会感到畏缩。我尝试过阅读它，但没有任何卡住。

普通英语到底是什么？

它只是将请求通过管道传输到终端并重定向输出吗？

点击查看英文原文

Every time I read either WSGI or CGI I cringe. I’ve tried reading on it before but nothing really has stuck.

What is it really in plain English?

Does it just pipe requests to a terminal and redirect the output?

回答 0

WSGI在Web服务器启动时（作为Web服务器进程的一部分（嵌入式模式）或作为单独的进程（守护程序模式））运行Python解释器，并将脚本加载到其中。每个请求都会导致调用脚本中的特定功能，并将请求环境作为参数传递给该功能。

CGI将脚本作为每个请求的单独进程运行，并使用环境变量，stdin和stdout与之“通信”。

点击查看英文原文

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.

CGI runs the script as a separate process each request and uses environment variables, stdin, and stdout to “communicate” with it.

回答 1

从完全后退的角度来看，Blankman，这是我的Web服务网关接口的“简介页”：

第一部分：网络服务器

Web服务器提供响应。他们坐在那里，耐心等待，然后突然没有任何警告：

  • 客户端进程发送请求。客户端进程可以是Web服务器，机器人，移动应用程序等。简直就是“客户”
  • Web服务器收到此请求
  • 故意咕umble各种事情发生（见下文）
  • Web服务器将某些内容发送回客户端
  • Web服务器再次坐在附近

Web服务器（至少是更好的服务器）在这方面非常擅长。他们根据需求扩展和缩减处理，通过可靠的网络可靠地与最薄弱的客户进行对话，而我们永远不必担心。他们只是继续服役。

这就是我的观点：Web服务器就是：服务器。他们对内容一无所知，对用户一无所知，实际上除了如何耐心等待和可靠答复外，一无所知。

您选择的Web服务器应该反映您的交付偏好，而不是您的软件。您的网络服务器应负责服务，而不是处理或逻辑事务。

第二部分：（PYTHON）软件

软件不存在。软件仅在执行时存在。当软件在其环境中发生意外更改（文件不在期望的位置，重命名参数等）时，软件并不适应。尽管优化应该是设计的中心原则（当然），但是软件本身并不能优化。开发人员乐观。软件执行。软件会执行上面“故意含糊不清”部分中的所有内容。可以是任何东西。

您对软件的选择或设计应反映您的应用程序，功能的选择，而不是Web服务器的选择。

这是将语言“编译”到Web服务器的传统方法变得很痛苦的地方。您最终将代码放入应用程序中以应对物理服务器环境，或者至少被迫选择一个适当的“包装”库以在运行时包括在内，从而使跨Web服务器具有统一性的错觉。

那么WSGI是什么？

那么，最后，WSGI是什么？WSGI是一套规则，分为两部分。编写它们的方式可以将它们集成到任何欢迎集成的环境中。

为Web服务器端编写的第一部分说：“好吧，如果您要处理WSGI应用程序，则这是该软件在加载时的思考方式。这是您必须为应用程序提供的内容，这里是您可以期望每个应用程序具有的界面（布局）。此外，如果出现任何问题，这是应用程序的思维方式以及期望行为的方式。”

为Python应用程序软件编写的第二部分说：“好吧，如果您要处理WSGI服务器，这是服务器与您联系时的思考方式。这是您必须向服务器提供的东西，以及这是您可以期望每台服务器都具有的接口（布局）。此外，如果出现任何问题，这是您的行为方式，也应该告诉服务器。”

因此，有了它-服务器将成为服务器，软件将成为软件，这是它们可以很好地相处的一种方式，而不必为彼此的细节留出余地。这是WSGI。

mod_wsgi的，而另一方面，是Apache的一个插件，让它跟WSGI兼容的软件，换句话说，mod_wsgi的是一个实现 -在Apache中-上面的规则手册第一部分的规则。

至于CGI ….问其他人:-)

点击查看英文原文

From a totally step-back point of view, Blankman, here is my “Intro Page” for Web Services Gateway Interface:

PART ONE: WEB SERVERS

Web servers serve up responses. They sit around, waiting patiently, and then with no warning at all, suddenly:

  • 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 mumble various things happen (see below)
  • The web server sends back something to the client
  • web server sits around again

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.

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.

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.

PART TWO: (PYTHON) SOFTWARE

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.

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.

SO WHAT IS 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.

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

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

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.

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.

As for CGI…. ask someone else :-)

回答 2

如果您不清楚这个领域中的所有术语，并且让我们面对现实，那是一个令人困惑的首字母缩写词，那么还有一个很好的背景阅读器，以官方的Python HOWTO形式提供，它讨论了CGI，FastCGI，WSGI等。上。希望我先读。

点击查看英文原文

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 HOWTO which discusses CGI vs. FastCGI vs. WSGI and so on. I wish I’d read it first.

回答 3

CGI和WSGI都定义了标准接口，程序可以使用这些标准接口来处理Web请求。CGI接口的级别低于WSGI，它涉及服务器设置环境变量，该环境变量包含HTTP请求中的数据，程序返回的格式类似于裸HTTP服务器响应。

另一方面，WSGI是特定于Python的更高级别的接口，它使程序员可以编写与服务器无关的应用程序，并且可以将其包装在其他WSGI应用程序（中间件）中。

点击查看英文原文

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.

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