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.
My concern is mostly that it is error-prone to leave it to the server, because it's not something you can pass upward easily (AFAICT). I know my middleware is mostly not compliant with this part of the spec, and it's not even clear to me how I'd fix them all. I'm sure I could figure it out, but most of WSGI doesn't require deep thought (and I like that), and this part doesn't feel like that to me.
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.
I'm trying to outsmart the servers, because I want to be able to control the error handling independent of servers. I'm trying to advocate that servers be as dumb as possible, and I expect to trust them as little as possible, so I don't want to leave stuff up to them. And showing partial responses is just Hard -- all the more reason to avoid leaving it up to servers with all the implementations that exist.
The error catching middleware is important to me, because I think that's a big part of a compelling web development experience (and something where Python works quite nicely). But I don't expect lots of implementations of error catchers, or at least those implementations *already* require thought.
Well, I guess the idea is to let the error middleware do its thing, but give the server an option to bail out gracefully if necessary (by raising the exception passed in). I think it's actually reasonable to have the server bail out ungracefully -- or the middleware -- in those few cases where there's a conflict. It mostly only applies to cases where there's errors in the streamed output, which seems unlikely to me (at least in cases where there's interactive debugging via a web browser).
Now that I'm thinking about it, can you remind me why WSGI doesn't work like this:
status, headers, body_iter = application(environ) print status print headers... for block in body_iter: ... body_iter.close()
Why is there a start_response and then a separate return?
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
