wsgi的environ变量

The environ dictionary is required to contain these CGI environment variables, as defined by the Common Gateway Interface specification
The following variables must be present(存在), unless their value would be an empty string, in which case they may be omitted(省略), except as otherwise noted below.

REQUEST_METHOD(请求方法)
The HTTP request method, such as "GET" or "POST". This cannot ever be an empty string, and so is always required.

SCRIPT_NAME
The initial portion of the request URL’s “path” that corresponds to the application object, so that the application knows its virtual “location”.
This may be an empty string, if the application corresponds to the “root” of the server.

PATH_INFO(请求的地址)
The remainder of the request URL’s “path”, designating the virtual “location” of the request’s target within the application.
This may be an empty string, if the request URL targets the application root and does not have a trailing slash.

QUERY_STRING(URL中传递的参数)
The portion of the request URL that follows the "?", if any. May be empty or absent.

CONTENT_TYPE
The contents of any Content-Type fields in the HTTP request. May be empty or absent.

CONTENT_LENGTH
The contents of any Content-Length fields in the HTTP request. May be empty or absent.

SERVER_NAME, SERVER_PORT
When combined with SCRIPT_NAME and PATH_INFO, these variables can be used to complete the URL.
Note, however, that HTTP_HOST, if present, should be used in preference to SERVER_NAME for reconstructing the request URL.
See the URL Reconstruction section below for more detail.
SERVER_NAME and SERVER_PORT can never be empty strings, and so are always required.(SERVER_NAME和SERVER_PORT永远不能是空字符串，因此总是必需的)

SERVER_PROTOCOL
The version of the protocol the client used to send the request. Typically this will be something like
"HTTP/1.0" or "HTTP/1.1" and may be used by the application to determine how to treat any HTTP request headers.
(This variable should probably be called REQUEST_PROTOCOL, since it denotes the protocol used in the request, and is not necessarily the protocol that will be used in the server’s response.
However, for compatibility with CGI we have to keep the existing name.
因为它表示在请求中使用的协议，而不一定是将在服务器响应中使用的协议。但是，为了与CGI兼容，我们必须保留现有的名称)

HTTP_ Variables
Variables corresponding to the client-supplied HTTP request headers (i.e., variables whose names begin with "HTTP_").
The presence or absence of these variables should correspond with the presence or absence of the appropriate HTTP header in the request.
A server or gateway should attempt to provide as many other CGI variables as are applicable.
In addition, if SSL is in use, the server or gateway should also provide as many of the Apache SSL environment variables as are applicable, such as HTTPS=on and SSL_PROTOCOL.
Note, however, that an application that uses any CGI variables other than the ones listed above are necessarily non-portable to web servers that do not support the relevant extensions. (For example, web servers that do not publish files will not be able to provide a meaningful DOCUMENT_ROOT or PATH_TRANSLATED.)

A WSGI-compliant server or gateway should document what variables it provides, along with their definitions as appropriate. Applications should check for the presence of any variables they require, and have a fallback plan in the event such a variable is absent.

Note: missing variables (such as REMOTE_USER when no authentication has occurred) should be left out of the
environ dictionary. Also note that CGI-defined variables must be strings, if they are present at all. It is a violation of this specification for a CGI variable’s value to be of any type other than str.
注意:应该将遗漏的变量(如未发生身份验证时的REMOTE_USER)从环境字典中删除。还请注意，如果存在的话，cgi定义的变量必须是字符串。将CGI变量的值设置为str以外的任何类型都是违反此规范的

In addition to the CGI-defined variables, the environ dictionary may also contain arbitrary operating-system “environment variables”, and must contain the following WSGI-defined variables:
除了cgi定义的变量外，环境字典还可以包含任意操作系统的“环境变量”，并且必须包含以下wsgi定义的变量:

wsgi.version
The tuple (1, 0), representing WSGI version 1.0.

wsgi.url_scheme
A string representing the “scheme” portion of the URL at which the application is being invoked. Normally, this will have the value "http" or "https", as appropriate.

wsgi.input
An input stream (file-like object) from which the HTTP request body can be read. (The server or gateway may perform reads on-demand as requested by the application, or it may pre- read the client’s request body and buffer it in-memory or on disk, or use any other technique for providing such an input stream, according to its preference.)

wsgi.errors
An output stream (file-like object) to which error output can be written, for the purpose of recording program or other errors in a standardized and possibly centralized location. This should be a “text mode” stream; i.e., applications should
use "n" as a line ending, and assume that it will be converted to the correct line ending by the server/gateway.

For many servers, wsgi.errors will be the server’s main error log. Alternatively, this may be
sys.stderr, or a log file of some sort. The server’s documentation should include an explanation of how to configure this or where to find the recorded output. A server or gateway may supply different error streams to different
applications, if this is desired.

wsgi.multithread
This value should evaluate true if the application object may be simultaneously invoked by another thread in the same process, and should evaluate false otherwise.

wsgi.multiprocess
This value should evaluate true if an equivalent application object may be simultaneously invoked by another process, and should evaluate false otherwise.

wsgi.run_once
This value should evaluate true if the server or gateway expects (but does not guarantee!) that the application will only be invoked this one time during the life of its containing process. Normally, this will only be true for a gateway based on CGI (or something similar).

Finally, the environ dictionary may also contain server-defined variables. These variables should be named using only lower-case letters, numbers, dots, and underscores, and should be prefixed with a name that is unique to the defining server or gateway. For example, mod_python might define variables with names like mod_python.some_variable.
 
转载 http://blog.360converter.com/archives/1024