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

[Ian Bicking]

Phillip J. Eby wrote:
> 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.  

I can't imagine we would make it.  Hopefully we produce something for 
2.5, that can be installed on previous Python installations under the 
same name.  (Not like optparse/optik)

I would hope that we can come to some consensus and produce something 
useable before 2.5, with the understanding that it will be included in 
2.5.  I would kind of like to see a "web" package.

> 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)

You've noted these are missing error handling.  What kind were you 
thinking of specifically?

There's exception handling, which seems straight forward.  Spec 
compliance?  Certainly an anal version of these servers should be 
written, that checks every type passed around, looks for common 
mistakes, etc.  I don't know if the anal and the useable version need to 
be the same thing.

Did you have any other error cases you were thinking of?

>  * WSGI app that wraps CGI applications so they can run under WSGI

Two models -- one that optimistically tries to load the cgi module in a 
fake environment (what I did), plus another that actually runs any CGI 
script.  And maybe another one that forks and ultimately dies, can run 
any Python CGI script, but saves some startup time.  But that last one 
isn't that important.

>  * 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.

If we use email.Message, using a status header seems fine.  If not, I 
think it should be separate -- I don't want to search a list for the 
status header.

I don't think the utility functions are a big deal at all, and I worry 
that there's some gotchas to email.Message, specifically where it is 
intended for email.  So I'm certainly not adamantly opposed to 
email.Message, but I'm not adamantly for it either.  I'd rather see a 
superclass of email.Message (such a superclass does not yet exist, but 
should be easy to write/extract) that is more minimal.

> 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.

To me it doesn't feel like the middleware is modifying the output.  It 
is augmenting the output in a case where there has been an unexpected 
failure.  I guess that could cause a problem, but then I think any 
middleware that is sensitive to the response being modified must still 
always allow for extra response coming in through normal channels.

But, I don't know.  I'm still up in the air.  Really, I just don't like 
wrapping start_response, from a mechanical point of view.  It feels 
awkward to me.  I wish I could just query the server as to what point in 
the response it is at.

> 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.

That seems too hard.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org