More formatting fixes

This commit is contained in:
Phillip J. Eby 2004-09-01 04:59:21 +00:00
parent 6690980d6b
commit 1bff7b795e
1 changed files with 45 additions and 47 deletions

View File

@ -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