[Web-SIG] WSGI start_response exc_info argument
Phillip J. Eby
pje at telecommunity.com
Wed Mar 30 18:49:09 CEST 2005
At 10:54 PM 3/29/05 -0600, Ian Bicking wrote:
>I realize I've been making invalid WSGI middleware for a while now. I
>guess I kind of knew that I was. Anyway, reviewing the spec again and
>looking at the exc_info argument to start_response, I feel a little
>unsure. I think I actually somehow got that argument in there by way of
>some argument I made, but I can't remember what, and it doesn't make sense
>to me now.
IIRC, it wasn't you, but Tony Lownds.
> Relevent sections:
>It seems like, in the small number of cases where this matters (basically
>error catching middleware and actual servers) it's easy enough to just
>code this up normally, I guess I don't see why the extra argument is
>needed to pass the error up the stack...?
That's not the use case. The parameter exists so error handling code
doesn't have to care whether start_response has already been called. Thus,
applications and middleware can be simpler because they don't need to track
that bit of state information that the server is already tracking. So,
calling start_response when it has already been called causes the error
handler to abort and fall back to the next higher error handler, all the
way up to the "real" server. IOW, it's a way of guaranteeing immediate
request termination if an error occurs once the response has begun.
Of course, any logging or notification error handlers in the stack will
receive the error in the normal way; it's just that if they also try to
start a response, they'll be aborted and the error will bubble up to the
next handler. Does that make more sense now?
More information about the Web-SIG