[Web-SIG] PEP 333 Update

[Phillip J. Eby]

I'm about to check in a major update to PEP 333; it should be available on 
the PEPs page within about an hour, and from SF CVS some time 
thereafter.  Here is a summary of the changes:

* Added 'wsgi.url_scheme', and updated sections relating thereto (such as 
the "URL Reconstruction" algorithm)

* Replaced the old "Optional Platform-Specific File Handling" section with 
a new one based on 'wsgi.file_wrapper', and expunged all references in the 
rest of the PEP that so much as suggest that returning a file or file-like 
object from an application is something you should ever do.

* Significantly expanded the "Error Handling" section, and other sections 
that relate to the new 'exc_info' parameter to 'start_response()'.

* Changed the definition of 'start_response' such that headers are not 
immediately sent to the client.

* Revised the "CGI gateway" example to include error handling and delayed 
header-sending.

* Miscellaneous explanatory clean-ups, such as linking from the 
specification regarding the use of 'len()' on the returned iterable, to the 
section of the spec that explains why using 'len()' is sometimes helpful.

* Added a (very brief) explanation of why returning an iterable is 
preferable to using 'write()', if the latter can be avoided, and noted that 
'write()' must not be invoked from within the returned iterable.

* Removed requirement that status and headers be pure 7-bit ASCII, 
referring instead to the RFC 2616 definitions.  (But left in the no-folding 
requirement that's specific to the PEP.)

* Added notes on using 'environ' to supply an application with limited 
configuration data

* Removed open issues that are now closed; added an open issue for 
reviewing the currently-required CGI variables, as it may be that some of 
them don't really need to be required.

* Added more kudos for Tony and Alan in the acknowledgements section.

We are now getting very close to finalization, I think.  There are just two 
more open issues to cover, plus some possible re-organization for 
HTTP/1.1-specifc stuff.  After that, I think we should post to python-list 
and python-dev one last time, then finalize the PEP.  After that, the 
semantics would be frozen, and only changes to e.g. the Q&A section, or 
edits for clarity would be allowed.  At that point, framework and server 
developers can then feel comfortable releasing something and calling it PEP 
333-compatible, if in fact it is.  :)