[Web-SIG] WSGI start_response exc_info argument

[Phillip J. Eby]

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:
>
>http://www.python.org/peps/pep-0333.html#the-start-response-callable
>http://www.python.org/peps/pep-0333.html#error-handling
>
>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?