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