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?
_______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
