ianb at colorstudy.com
Thu Sep 2 08:28:11 CEST 2004
Phillip J. Eby wrote:
> At 11:15 PM 8/30/04 -0700, tony at lownds.com wrote:
>> > Here are some changes I've proposed in the last few days to resolve
>> > people brought up, but which I haven't gotten much feedback on:
>> > * 'wsgi.fatal_errors' key for exceptions that apps and middleware
>> > shouldn't
>> > trap
>> What about defining an exception class that applications can raise
>> with an
>> HTML payload, which servers are supposed to send the to the client?
>> Middleware should be free to alter the payload as much as they like. The
>> server should not send the payload when content-type is not html.
>> By using exceptions as a backchannel, the application and middleware do
>> not have to keep track of the state to sanely handle an error.
> Interesting. But I think you've just given me an idea for a possibly
> simpler way to do this, with some other advantages.
> Suppose that instead of 'start_response(status,headers)' we had
> 'set_response(status,headers,body=None)'. And the difference would be
> that our 'set_response' does nothing until/unless you call write() or
> yield a result from the return iterable. Therefore, you could call
> 'set_response' multiple times, with only the last such call taking
> effect. (If you supply a non-None 'body', then calling write() or
> returning an iterable is an error.)
This seems pretty reasonable. How necessary is that optional body
argument? Couldn't you just use the write argument or return an iterable?
> Now consider error handling middleware: it simply calls
> 'set_response(error_status,error_headers,error_body)', and returns None.
> At this point, we've isolated the complexity to exist only for streaming
> responses once the first body chunk has been generated. We can handle
> this by making a call to 'set_response()' a fatal error if a body chunk
> has been generated. Thus, no special handling is needed by an exception
> handler: it just tries to do 'set_response()', and allows the fatal
> error (if any) to propagate. Now, the server can catch the fatal error
> and deal with it.
> I think this will let us keep all of the complications in the server,
> where they always have to exist, no matter what else we do.
> Exception-handling middleware is then delightfully simple.
> On the other hand, output-transforming middleware becomes somewhat more
> complex, as it would now have three output sources to transform (body
> param to set_response(), write(), and output iterable).
> This is a fairly significant change to the spec, that introduces lots of
> new angles to cover. But, I think it could be an "exceptionally" clean
> solution to the problem. ;)
It sounded good until then; now I don't know. I think I'm -1 on that pun.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG