[Web-SIG] wsgi.fatal_errors

[Ian Bicking]

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