More formatting fixes
This commit is contained in:
parent
6690980d6b
commit
1bff7b795e
92
pep-0333.txt
92
pep-0333.txt
|
@ -204,16 +204,14 @@ omitted)::
|
||||||
environ['wsgi.last_call'] = True
|
environ['wsgi.last_call'] = True
|
||||||
|
|
||||||
def write(data):
|
def write(data):
|
||||||
sys.stdout.write(data)
|
sys.stdout.write(data)
|
||||||
sys.stdout.flush()
|
sys.stdout.flush()
|
||||||
|
|
||||||
def start_response(status,headers):
|
def start_response(status,headers):
|
||||||
|
|
||||||
sys.stdout.write("Status: %s\r\n" % status)
|
sys.stdout.write("Status: %s\r\n" % status)
|
||||||
for key,val in headers:
|
for key,val in headers:
|
||||||
sys.stdout.write("%s: %s\r\n" % (key,val))
|
sys.stdout.write("%s: %s\r\n" % (key,val))
|
||||||
sys.stdout.write("\r\n")
|
sys.stdout.write("\r\n")
|
||||||
|
|
||||||
return write
|
return write
|
||||||
|
|
||||||
result = application(environ, start_response)
|
result = application(environ, start_response)
|
||||||
|
@ -333,30 +331,30 @@ specification [2]_. The following variables **must** be present, but
|
||||||
**may** be an empty string, if there is no more appropriate value for
|
**may** be an empty string, if there is no more appropriate value for
|
||||||
them:
|
them:
|
||||||
|
|
||||||
* ``REQUEST_METHOD``
|
* ``REQUEST_METHOD``
|
||||||
|
|
||||||
* ``SCRIPT_NAME`` (The initial portion of the request URL's "path"
|
* ``SCRIPT_NAME`` (The initial portion of the request URL's "path"
|
||||||
that corresponds to the application object, so that the application
|
that corresponds to the application object, so that the application
|
||||||
knows its virtual "location".)
|
knows its virtual "location".)
|
||||||
|
|
||||||
* ``PATH_INFO`` (The remainder of the request URL's "path",
|
* ``PATH_INFO`` (The remainder of the request URL's "path",
|
||||||
designating the virtual "location" of the request's target within
|
designating the virtual "location" of the request's target within
|
||||||
the application)
|
the application)
|
||||||
|
|
||||||
* ``QUERY_STRING``
|
* ``QUERY_STRING``
|
||||||
|
|
||||||
* ``CONTENT_TYPE``
|
* ``CONTENT_TYPE``
|
||||||
|
|
||||||
* ``CONTENT_LENGTH``
|
* ``CONTENT_LENGTH``
|
||||||
|
|
||||||
* ``SERVER_NAME`` and ``SERVER_PORT`` (which, when combined with
|
* ``SERVER_NAME`` and ``SERVER_PORT`` (which, when combined with
|
||||||
``SCRIPT_NAME`` and ``PATH_INFO``, should complete the URL. Note,
|
``SCRIPT_NAME`` and ``PATH_INFO``, should complete the URL. Note,
|
||||||
however, that ``HTTP_HOST``, if present, should be used in
|
however, that ``HTTP_HOST``, if present, should be used in
|
||||||
preference to ``SERVER_NAME`` for constructing the URL. See the
|
preference to ``SERVER_NAME`` for constructing the URL. See the
|
||||||
`URL Reconstruction`_ section below for more detail.)
|
`URL Reconstruction`_ section below for more detail.)
|
||||||
|
|
||||||
* Variables corresponding to the client-supplied HTTP headers (i.e.,
|
* Variables corresponding to the client-supplied HTTP headers (i.e.,
|
||||||
variables whose names begin with ``"HTTP_"``).
|
variables whose names begin with ``"HTTP_"``).
|
||||||
|
|
||||||
In general, a server or gateway should attempt to provide as many
|
In general, a server or gateway should attempt to provide as many
|
||||||
other CGI variables as are applicable, including e.g. the nonstandard
|
other CGI variables as are applicable, including e.g. the nonstandard
|
||||||
|
@ -752,16 +750,16 @@ to some application(s), while also acting as an application with
|
||||||
respect to some server(s). Such "middleware" components can perform
|
respect to some server(s). Such "middleware" components can perform
|
||||||
such functions as:
|
such functions as:
|
||||||
|
|
||||||
* Routing a request to different application objects based on the
|
* Routing a request to different application objects based on the
|
||||||
target URL, after rewriting the ``environ`` accordingly.
|
target URL, after rewriting the ``environ`` accordingly.
|
||||||
|
|
||||||
* Allowing multiple applications or frameworks to run side-by-side
|
* Allowing multiple applications or frameworks to run side-by-side
|
||||||
in the same process
|
in the same process
|
||||||
|
|
||||||
* Load balancing and remote processing, by forwarding requests and
|
* Load balancing and remote processing, by forwarding requests and
|
||||||
responses over a network
|
responses over a network
|
||||||
|
|
||||||
* Perform content postprocessing, such as applying XSL stylesheets
|
* Perform content postprocessing, such as applying XSL stylesheets
|
||||||
|
|
||||||
Given the existence of applications and servers conforming to this
|
Given the existence of applications and servers conforming to this
|
||||||
specification, the appearance of such reusable middleware becomes
|
specification, the appearance of such reusable middleware becomes
|
||||||
|
@ -874,18 +872,18 @@ Servers and gateways **must** provide transparent support for HTTP
|
||||||
1.1's "expect/continue" mechanism, if they implement HTTP 1.1. This
|
1.1's "expect/continue" mechanism, if they implement HTTP 1.1. This
|
||||||
may be done in any of several ways:
|
may be done in any of several ways:
|
||||||
|
|
||||||
1. Reject all client requests containing an ``Expect: 100-continue``
|
1. Reject all client requests containing an ``Expect: 100-continue``
|
||||||
header with a "417 Expectation failed" error. Such requests will
|
header with a "417 Expectation failed" error. Such requests will
|
||||||
not be forwarded to an application object.
|
not be forwarded to an application object.
|
||||||
|
|
||||||
2. Respond to requests containing an ``Expect: 100-continue`` request
|
2. Respond to requests containing an ``Expect: 100-continue`` request
|
||||||
with an immediate "100 Continue" response, and proceed normally.
|
with an immediate "100 Continue" response, and proceed normally.
|
||||||
|
|
||||||
3. Proceed with the request normally, but provide the application
|
3. Proceed with the request normally, but provide the application
|
||||||
with a ``wsgi.input`` stream that will send the "100 Continue"
|
with a ``wsgi.input`` stream that will send the "100 Continue"
|
||||||
response if/when the application first attempts to read from the
|
response if/when the application first attempts to read from the
|
||||||
input stream. The read request must then remain blocked until the
|
input stream. The read request must then remain blocked until the
|
||||||
client responds.
|
client responds.
|
||||||
|
|
||||||
Note that this behavior restriction does not apply for HTTP 1.0
|
Note that this behavior restriction does not apply for HTTP 1.0
|
||||||
requests, or for requests that are not directed to an application
|
requests, or for requests that are not directed to an application
|
||||||
|
@ -1071,18 +1069,18 @@ Acknowledgements
|
||||||
Thanks go to the many folks on the Web-SIG mailing list whose
|
Thanks go to the many folks on the Web-SIG mailing list whose
|
||||||
thoughtful feedback made this revised draft possible. Especially:
|
thoughtful feedback made this revised draft possible. Especially:
|
||||||
|
|
||||||
* Gregory "Grisha" Trubetskoy, author of ``mod_python``, who beat up
|
* Gregory "Grisha" Trubetskoy, author of ``mod_python``, who beat up
|
||||||
on the first draft as not offering any advantages over "plain old
|
on the first draft as not offering any advantages over "plain old
|
||||||
CGI", thus encouraging me to look for a better approach.
|
CGI", thus encouraging me to look for a better approach.
|
||||||
|
|
||||||
* Ian Bicking, who helped nag me into properly specifying the
|
* Ian Bicking, who helped nag me into properly specifying the
|
||||||
multithreading and multiprocess options, as well as badgering me to
|
multithreading and multiprocess options, as well as badgering me to
|
||||||
provide a mechanism for servers to supply custom extension data to
|
provide a mechanism for servers to supply custom extension data to
|
||||||
an application.
|
an application.
|
||||||
|
|
||||||
* Tony Lownds, who came up with the concept of a ``start_response``
|
* Tony Lownds, who came up with the concept of a ``start_response``
|
||||||
function that took the status and headers, returning a ``write``
|
function that took the status and headers, returning a ``write``
|
||||||
function.
|
function.
|
||||||
|
|
||||||
|
|
||||||
References
|
References
|
||||||
|
|
Loading…
Reference in New Issue