diff --git a/pep-0333.txt b/pep-0333.txt index de74034e6..0546c2cc4 100644 --- a/pep-0333.txt +++ b/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