[Web-SIG] WSGI start_response exc_info argument

[Phillip J. Eby]

At 01:21 PM 3/30/05 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>It really should capture the headers, and maybe buffer them itself (in 
>>>which case it would also have to intercept the writer), so that it can 
>>>deal more gracefully with a case where content type is set or 
>>>something.  But all that annoying stuff is better kept to this one piece 
>>>of middleware, instead of making everything more difficult with that 
>>>extra argument to start_response.
>>
>>Um, the argument is *precisely* there so you don't need all of that! Try 
>>this:
>
>But I don't mind all of that, because it is only contained in the error 
>catching middleware and no where else.  I have other middleware that 
>overrides start_response, and don't want to bother with all the exc_info 
>in that case.

Just pass it through to the upstream start_response; the top-level server 
is the only one that needs to care.


>   And a lot of the logic -- like trying to show errors even when there's 
> been a partial response -- is just work, there's no way to get around it.

So leave it to the server.  All I'm saying is that there is no need to 
track whether the response has started.  It's the server's job to know 
that, and the opinion of middleware doesn't count here.  As long as the 
*server* hasn't sent the headers yet, you can restart the response.

Therefore, the correct way to send an error is for the error handler to 
pass exc_info to start_response, and middleware start_response() functions 
*must* pass that upward unless they definitely know better.  (E.g. because 
they're buffering and know the upstream start_response hasn't started yet.)

The point I'm trying to make here is that you seem to be trying to outsmart 
WSGI on this point; only the server is in a position to show an error in 
the case of a partial response, because it's the only component that 
definitively knows what has or hasn't been sent to the client.