[Web-SIG] Stuff left to be done on WSGI
ianb at colorstudy.com
Sat Aug 28 02:00:18 CEST 2004
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
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
More information about the Web-SIG