[Web-SIG] Pending modifications to PEP 333

[Phillip J. Eby]

I'm just about to check in a major update to the PEP, per the details 
below.  It will be a while before it shows up in the HTML version of the 
PEP or the sourceforge ViewCVS, though.


At 11:25 PM 8/29/04 -0400, Phillip J. Eby wrote:
>Here are some changes I've proposed in the last few days to resolve issues 
>people brought up, but which I haven't gotten much feedback on:
>
>* 'wsgi.fatal_errors' key for exceptions that apps and middleware 
>shouldn't trap
>
>* 'wsgi.auth_available' flag

I've added these to the "Open Issues" section now


>* Make the 'headers' object an 'email.Message' (well, there's been some 
>feedback, but I think I addressed the concerns, and there was no feedback 
>since)

...and removed this, because it's effectively dead due to lack of popular 
support, added annoyances, and the need to support pre-2.2 versions of 
Python.  However, I've updated the spec to be unambiguous in requiring a 
*list* of header tuples, so that middleware and servers can modify the 
headers in place using boilerplate routines, if desired.


>* what should a server or gateway's default error handling be, for each of 
>the eight contexts in which an exception can occur?

Added to open issues.


>* notes on writing pre-2.2 compatible iteration code

Completed and added to the PEP.


>* anything else?

The application object must now *always* return an iterable; 'None' is no 
longer a valid return value.  This simplifies server logic and helps 
encourage the use of an iterable.  Also, it's now explicit that the server 
must not try to use any attributes of the iterable not explicitly mentioned 
by the PEP (e.g. 'read()' is a no-no).

I've also clarified that 'fileno()', if present, *must* be an OS file 
descriptor, and is only relevant to servers on platforms where file 
descriptors exist.

I've also done a significant edit to further clarify that the 'write()' 
callable is a backward compatibility hack, and isn't intended to be used 
unless you really, really need it.  I've also significantly clarified the 
issues surrounding buffering and streaming.

I also refactored the examples to be more compliant with the spec's 
intentions and to be more explanatory/exemplary of desirable behaviors.

Last, but not least, the language regarding a server modifying or deleting 
application-supplied headers has been clarified to restrict its 
applicability to connection-management headers, and to clarify where any 
replaced or deleted headers should be recorded.