[Web-SIG] Stuff left to be done on WSGI

[Phillip J. Eby]

I don't know if it's possible for us to get these items together in time 
for 2.4; if we don't, we don't.  There's little harm in having a separate 
'wsgi' distribution until 2.5 rolls around.  I'm thinking the package 
should include:

  * BaseHTTPServer-based WSGI server
  * CGI-based WSGI gateway (run WSGI apps under CGI)
  * WSGI app that wraps CGI applications so they can run under WSGI
  * Utility routines to fulfill certain parts of the spec's requirements
  * HTTP/1.1 practice guidelines, and utility routines where appropriate
  * Documentation

This looks like quite a list to do in just a few days, despite the fact 
that we have skeleton implementations of the first four items and part of 
the fifth.  And that's completely ignoring these currently outstanding 
issues in the PEP itself:

   * List-of-tuples vs. email.Message for outgoing headers
   * Exception handling

Plus, I'm a couple days behind in updates to reflect the SIG's current 
consensus on other outstanding issues, and haven't done anything to 
separate the HTTP/1.1 guidelines out.

Anyway, we really need to finish the outstanding open issues, because until 
the spec is firm on those items, we're coding on sand in those areas.

I personally would like to use email.Message, and I'm even tempted to make 
'Status' a header, so that it's just 'start_response(headers)' instead of 
'start_response(status,headers)'.  The Content-Transfer-Encoding 
boilerplate is only needed by servers and gateways, and I don't think 
adding another two lines of code creates a big burden there.  But it makes 
middleware's job a lot easier: just add or modify headers, rather than 
having to turn the sequence of headers into some other structure and back 
again, or having to write utility routines to duplicate the functionality 
already in email.Message.

With regard to exception handling, Ian has pointed out that it's hard for 
middleware to trap exceptions well, because it can't tell whether the next 
app down the chain has written headers yet, unless it replaces 
'start_response', which then means it disables any advanced server APIs.

After thinking about this for a while, I'm having trouble seeing a problem 
with that.  Specifically, exception-catching middleware *is* modifying the 
output mechanism, because it will change the output in that case.  It 
doesn't seem to me that you can safely write exception-catching middleware 
that can work without disabling the use of extension APIs for application 
output.

The only other thing that comes to mind is requiring servers to support 
multiple 'start_response' calls in some way that makes sense for exception 
handlers, while requiring it to still work in the case where an extension 
API has already been used for output.