More formatting fixes
This commit is contained in:
Phillip J. Eby
parent
6690980d6b
commit
1bff7b795e
92
pep-0333.txt
92
pep-0333.txt
|
|
@ -204,16 +204,14 @@ omitted)::
|
|||
environ['wsgi.last_call'] = True
|
||||
|
||||
def write(data):
|
||||
sys.stdout.write(data)
|
||||
sys.stdout.write(data)
|
||||
sys.stdout.flush()
|
||||
|
||||
def start_response(status,headers):
|
||||
|
||||
sys.stdout.write("Status: %s\r\n" % status)
|
||||
for key,val in headers:
|
||||
sys.stdout.write("%s: %s\r\n" % (key,val))
|
||||
sys.stdout.write("\r\n")
|
||||
|
||||
return write
|
||||
|
||||
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
|
||||
them:
|
||||
|
||||
* ``REQUEST_METHOD``
|
||||
* ``REQUEST_METHOD``
|
||||
|
||||
* ``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".)
|
||||
* ``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".)
|
||||
|
||||
* ``PATH_INFO`` (The remainder of the request URL's "path",
|
||||
designating the virtual "location" of the request's target within
|
||||
the application)
|
||||
* ``PATH_INFO`` (The remainder of the request URL's "path",
|
||||
designating the virtual "location" of the request's target within
|
||||
the application)
|
||||
|
||||
* ``QUERY_STRING``
|
||||
* ``QUERY_STRING``
|
||||
|
||||
* ``CONTENT_TYPE``
|
||||
* ``CONTENT_TYPE``
|
||||
|
||||
* ``CONTENT_LENGTH``
|
||||
* ``CONTENT_LENGTH``
|
||||
|
||||
* ``SERVER_NAME`` and ``SERVER_PORT`` (which, when combined with
|
||||
``SCRIPT_NAME`` and ``PATH_INFO``, should complete the URL. Note,
|
||||
however, that ``HTTP_HOST``, if present, should be used in
|
||||
preference to ``SERVER_NAME`` for constructing the URL. See the
|
||||
`URL Reconstruction`_ section below for more detail.)
|
||||
* ``SERVER_NAME`` and ``SERVER_PORT`` (which, when combined with
|
||||
``SCRIPT_NAME`` and ``PATH_INFO``, should complete the URL. Note,
|
||||
however, that ``HTTP_HOST``, if present, should be used in
|
||||
preference to ``SERVER_NAME`` for constructing the URL. See the
|
||||
`URL Reconstruction`_ section below for more detail.)
|
||||
|
||||
* Variables corresponding to the client-supplied HTTP headers (i.e.,
|
||||
variables whose names begin with ``"HTTP_"``).
|
||||
* Variables corresponding to the client-supplied HTTP headers (i.e.,
|
||||
variables whose names begin with ``"HTTP_"``).
|
||||
|
||||
In general, a server or gateway should attempt to provide as many
|
||||
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
|
||||
such functions as:
|
||||
|
||||
* Routing a request to different application objects based on the
|
||||
target URL, after rewriting the ``environ`` accordingly.
|
||||
* Routing a request to different application objects based on the
|
||||
target URL, after rewriting the ``environ`` accordingly.
|
||||
|
||||
* Allowing multiple applications or frameworks to run side-by-side
|
||||
in the same process
|
||||
* Allowing multiple applications or frameworks to run side-by-side
|
||||
in the same process
|
||||
|
||||
* Load balancing and remote processing, by forwarding requests and
|
||||
responses over a network
|
||||
* Load balancing and remote processing, by forwarding requests and
|
||||
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
|
||||
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
|
||||
may be done in any of several ways:
|
||||
|
||||
1. Reject all client requests containing an ``Expect: 100-continue``
|
||||
header with a "417 Expectation failed" error. Such requests will
|
||||
not be forwarded to an application object.
|
||||
1. Reject all client requests containing an ``Expect: 100-continue``
|
||||
header with a "417 Expectation failed" error. Such requests will
|
||||
not be forwarded to an application object.
|
||||
|
||||
2. Respond to requests containing an ``Expect: 100-continue`` request
|
||||
with an immediate "100 Continue" response, and proceed normally.
|
||||
2. Respond to requests containing an ``Expect: 100-continue`` request
|
||||
with an immediate "100 Continue" response, and proceed normally.
|
||||
|
||||
3. Proceed with the request normally, but provide the application
|
||||
with a ``wsgi.input`` stream that will send the "100 Continue"
|
||||
response if/when the application first attempts to read from the
|
||||
input stream. The read request must then remain blocked until the
|
||||
client responds.
|
||||
3. Proceed with the request normally, but provide the application
|
||||
with a ``wsgi.input`` stream that will send the "100 Continue"
|
||||
response if/when the application first attempts to read from the
|
||||
input stream. The read request must then remain blocked until the
|
||||
client responds.
|
||||
|
||||
Note that this behavior restriction does not apply for HTTP 1.0
|
||||
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
|
||||
thoughtful feedback made this revised draft possible. Especially:
|
||||
|
||||
* Gregory "Grisha" Trubetskoy, author of ``mod_python``, who beat up
|
||||
on the first draft as not offering any advantages over "plain old
|
||||
CGI", thus encouraging me to look for a better approach.
|
||||
* Gregory "Grisha" Trubetskoy, author of ``mod_python``, who beat up
|
||||
on the first draft as not offering any advantages over "plain old
|
||||
CGI", thus encouraging me to look for a better approach.
|
||||
|
||||
* Ian Bicking, who helped nag me into properly specifying the
|
||||
multithreading and multiprocess options, as well as badgering me to
|
||||
provide a mechanism for servers to supply custom extension data to
|
||||
an application.
|
||||
* Ian Bicking, who helped nag me into properly specifying the
|
||||
multithreading and multiprocess options, as well as badgering me to
|
||||
provide a mechanism for servers to supply custom extension data to
|
||||
an application.
|
||||
|
||||
* Tony Lownds, who came up with the concept of a ``start_response``
|
||||
function that took the status and headers, returning a ``write``
|
||||
function.
|
||||
* Tony Lownds, who came up with the concept of a ``start_response``
|
||||
function that took the status and headers, returning a ``write``
|
||||
function.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
Loading…
Reference in New Issue