[Web-SIG] Reviewing WSGI open issues, again...

Phillip J. Eby pje at telecommunity.com
Thu Sep 9 02:43:09 CEST 2004


* HTTP_AUTHENTICATION -- I haven't seen a concrete proposal for this yet, 
and I don't personally consider it a high priority.  If something is to go 
in for this, somebody needs to put together a proposal, preferably in the 
form of a patch to the PEP.

* Byte strings: so far the only discussion here has centered on character 
sets required by HTTP RFCs.  I'm going to loosen up the ASCII status/header 
requirement slightly, to indicate that ISO-8859-1 is acceptable encoding, 
per RFC 2616.  Any other comments regarding byte string issues?

* Error handling -- I'm assuming the SIG consensus is +1 on the 
'wsgi.fatal_errors' key, but haven't seen any feedback on my ideas for 
'start_response', except that I seem to recall someone saying they didn't 
want the body passed to start_response.  Taking that part out, we end up 
with something like this:

'start_response()' doesn't actually transmit the status or headers until 
the first write() call occurs or the first string is yielded from the 
returned iterable.  'start_response' simply stores the status or headers 
for future use, and may therefore be called more than once.  However, 
calling 'start_response()' *after* a write(), or after the first string is 
yielded, is a fatal error.  Top-level servers/gateways should log detailed 
information about errors that occur after a partial result is 
transmitted.  They may also attempt to send error information to the client 
if the content type is text (e.g. text/html, text/xml, text/plain).

Feedback, anyone?

* File-like objects -- I think anything we offer for file-like objects 
should be optional.  The big question is whether to offer a single, 
introspection-based extension for all file-like things, or whether to use 
separate extensions for different sorts of things, like 'wsgi.fd_wrapper' 
for file descriptors and 'wsgi.nio_wrapper' for Java NIO objects, 
etc.  Does anybody have any arguments/use cases one way or the other?

* Configuration -- I'm going to mention that servers *should* provide an 
easy way to configure name-value pairs to be supplied to an application's 
'environ', and that one way to do that is simply to include OS environment 
variables in 'environ'.

Am I missing anything else that's been discussed recently?  (E.g. just 
before I went into hiding from the hurricane...)



More information about the Web-SIG mailing list