[Web-SIG] WSGI start_response exc_info argument

[Ian Bicking]

Phillip J. Eby wrote:
>> 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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org