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.
_______________________________________________ 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
