Phillip J. Eby
pje at telecommunity.com
Thu Sep 2 15:42:51 CEST 2004
At 01:28 AM 9/2/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 11:15 PM 8/30/04 -0700, tony at lownds.com wrote:
>>>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?
The idea was to use it as a way to bypass non-exception middleware, without
raising a fatal error. OTOH, maybe Tony's approach is actually better.
>>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.
I get the humor of the second sentence; is the first sentence also humor,
or is it serious?
More information about the Web-SIG