[Web-SIG] Python Web Modules - Version 0.5.0

[James Gardner]

Ian Bicking wrote:

>> Another thing I noticed when writing the error handler is that if an 
>> application or middleware component doesn't form a header or set the 
>> status correctly it can be tricky to track down where the error 
>> occurred. If the application used a special object for headers and 
>> status in the start_response callable which raised an error when it 
>> was set with an invalid value that would make life easier.
>
> I'm not sure I understand you here.  What's the exact situation where 
> you encounter this?

Well, when I was programming the session middleware I appended a tuple 
of the wrong length to the headers used in start_response. This wasn't 
picked up until the error handling module by which time I had no idea 
which piece of middleware had appended the faulty header. If header was 
an object that behaved like a list but only allowed correctly formed 
headers to be appended this error would have been picked up where it 
happened.

>> One other thing I've been meaning to ask.. The WSGI specification 
>> currently allows no way for an application or middleware components 
>> to pass custom information back up the middleware chain so that an 
>> application can ask a middleware component not to perform a certain 
>> task if it needs to. Communication up the chain can only be provided 
>> through status, headers, exc_info and content. There could very 
>> easily also be a response dictionary added as another parameter to 
>> start_response, similar to environ which sent information up the 
>> chain. Was this deliberately avoided so that the system wouldn't get 
>> complicated?
>
> I was thinking about this too.  It certainly makes it simpler to make 
> the response fairly plain and HTTP-like, but I can imagine lots of 
> useful information that doesn't fit well into headers or response 
> codes.  E.g., if you are sending a 403 error message, maybe you want 
> to pass some extra information along about why it happened.  You could 
> write that out as the HTML response, but then it becomes somewhat 
> opaque if that gets rewritten.  Something like the extension 
> information that gets put in the request environment; it's always 
> purely optional, but there to allow cooperation between components.  
> There's no escape mechanism like that for the response.
>
> Well... there is a way, actually -- you can add callbacks to the 
> request.  For instance, in my session handler I add a callable to the 
> request that returns the session object.  If you don't call that at 
> all then the session isn't even created, and no session ID is assigned 
> (assuming you didn't already have a session).  If you do call it, then 
> the middleware modifies the response to add a session ID.  So there's 
> really some communication from the application that effects the 
> response, but it isn't being expressed as part of the response stream 
> (the status, headers, and body).

That's true and useful in the session case. In fact any middleware that 
needed the session store could still call the callable, they'd just need 
to check if it had already been called (or the callable itself could 
keep track of whether it had been called in fact). It does mean that 
other middleware components can't get access to the same information 
though unless they all chain callables down the middleware stack.

It doesn't really work for your first example with the error information 
though since the information should be available to all middleware 
components. In that example though couldn't the application send error 
information with exc_info and the auth middleware catch it or am I 
missing something?

Do you think there is mileage to be gained from adding a response 
dictionary to start_response as that would be a simple way of sending 
information back? It would break if existing WSGI apps didn't pass on 
the response dictionary though.

James
--
http://www.pythonweb.org/