[Web-SIG] WSGI start_response exc_info argument
Phillip J. Eby
pje at telecommunity.com
Wed Mar 30 21:58:43 CEST 2005
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
>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.
More information about the Web-SIG