The environ dictionary is required to contain these CGI environment variables, as defined by the Common Gateway Interface specification
[2]. 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
- 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_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.) - 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
[5] 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.
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:
| Variable | Value |
|---|---|
| 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 For many servers, wsgi.errors will be the server’s main error log. Alternatively, this may be |
| 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.
版权所有，禁止转载. 如需转载，请先征得博主的同意，并且表明文章出处，否则按侵权处理.
