[Web-SIG] WSGI start_response exc_info argument
ianb at colorstudy.com
Wed Mar 30 21:21:38 CEST 2005
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. 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.
> def __call__(self, environ, start_response):
> app_iter = self.application(environ, detect_start_response)
> start_response('500 Internal Server Error',
> [('content-type', 'text/html')],
> # etc...
> No need to track the startedness here, because the upstream
> start_response will reraise the error if you've already started, thus
> breaking out of the middleware and getting back to the calling server.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG