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

[Phillip J. Eby]

At 10:38 AM 9/11/04 -0700, tony at lownds.com wrote:
> > OTOH, we could simply have
> > an
> > optional third argument to start_response:
> >
> >      start_response(status,headers,sys.exc_info())
> >
> > the idea being that 'start_response' should reraise the exc_info tuple (or
> > some private exception type) if the response has already been started.  It
> > can also optionally log the error information.
> >
> > Note that this also allows middleware to trivially intercept error reports
> > by overriding start_response.  If it decides to handle the error itself,
> > the middleware can simply throw an exception that it then catches as the
> > app aborts.
> >
>
>That reasonably handles the exception case. Applications and middleware
>should never catch exceptions from start_response then, correct?

Not if the call to start_response() was made from an error handler, 
no.  But I think it's acceptable to catch errors from normal (2-argument) 
calls to start_response().


> > I think that we can meet this use case without a server-provided exception
> > class; the server (or middleware) just needs to know that you're starting
> > an error response, and what the error is.  Adding an argument to
> > start_response seems like a good, clean way to do this, and it looks easy
> > to use/implement on all sides.  What do you think?
> >
>
>I'm beginning to think that re-startability is important. It makes it much
>less likely that a successful HTTP code is returned when the application
>actually broke. Given that, I don't
>see much of an advantage to the exception.

Good.  We'll take the "third argument" approach, then.  It's going to 
expand the PEP quite a bit, but every error handling proposal so far was 
going to do that.  But this one handles your use case without adding much 
overhead for the more common cases.

I can't believe we've managed to get away without having *any* special 
environ keys for error handling or any custom exception classes (except 
when you want to do something special, of course).

I'm going to try and get all the updates into the PEP this weekend, 
hopefully before the next hurricane goes by.  If it comes too close and we 
lose power here, I don't expect we'll get it back for a week or two, as 
there are too many crews still out fixing power outages from the *last* 
hurricane!

Once all the pending updates are in, I think we'll be almost ready to 
finalize the PEP, and we should plan on another posting to python-list and 
python-dev, giving a finalization deadline and requesting that all 
remaining change requests be submitted in the form of a patch.

Hm.  Actually, that might be premature, since I recall we were planning to 
get the HTTP/1.1 stuff in order first.  Mark, how's that coming along?  :)