[Python-checkins] python/nondist/peps pep-0333.txt,1.4,1.5
pje at users.sourceforge.net
pje at users.sourceforge.net
Wed Sep 1 06:59:23 CEST 2004
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28642
Modified Files:
pep-0333.txt
Log Message:
More formatting fixes
Index: pep-0333.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0333.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- pep-0333.txt 31 Aug 2004 22:00:28 -0000 1.4
+++ pep-0333.txt 1 Sep 2004 04:59:21 -0000 1.5
@@ -204,16 +204,14 @@
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 @@
**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 @@
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 @@
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 @@
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
More information about the Python-checkins
mailing list