Ian Bicking wrote:
web.wsgi.error: one standard I'd like for middleware would be some key you could set that would indicate that some error handler exists, and applications further down the stack shouldn't catch unexpected exceptions (of course expected exceptions are a different matter). Then the best error handler available would eventually get the error, and process it somehow (e.g., mailing a report, displaying an error, starting a debugger, etc). Anyway, something to think about for this.
That could be useful. Presumably the middleware component nearest the server is likely to have the best error handling (as you would put the best error handler in a position to catch the most errors). So this could be as simple as agreeing a variable name like wsgi.error for the environ dictionary which the highest middleware component up the chain would set to True and ones lower down wouldn't provide error handling if it was already set.
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.
(Alternatively, if you wanted to change the way things were programmed a bit you could write your application as middleware and specify a terminator which set the headers and status using these special objects. Probably not necessary though!)
web.wsgi.auth: I've been thinking lot about this as well, particularly about the external interface. REMOTE_USER seems like a reasonable enough place to put the login information. I'd like to keep authorization and authentication separate -- one middleware determines who you are, another (might) determine if you are allowed access. Frequently only the application really knows if you are authorized, based on logic that's beyond any ability to make it generic.
Agreed, the underlying API makes this even more explicit than the web.wsgi.auth module.. I'll split web.wsgi.auth.Auth into two components, one for authentication and one for authorization. The existing web.wsgi.auth.Auth will just be a chain of the two components and then will have the same functionality.
So I was thinking that status codes should be sufficient to communicate authorization: 401 for login required, 403 for forbidden. If you are doing cookie logins (which I generally prefer from a UI perspective) the middleware can translate the 401 into a redirect to the login page. And the 403 can turn into a nicer error page --
So in a new version the authentication middleware would display a sign in box if no user was signed in, the authorization middleware would provide objects for the application to test authorisation and would also look for headers to determine whether the application thought the user was authorised and would display a sign in if not.
a piece of middleware for indicating error pages would also be nice (similar to Apache's ErrorDocument directive).
Agreed, I'll write one.
web.wsgi.session: I'd like to have some sort of standard for these objects, at least some aspects. Not the details of storage, but mostly access; along the lines of web.session.manager and/or .store. I'm not sure how I feel about the manager with multiple applications, each of which has a store -- I feel like this should be part of the configuration somehow, which isn't necessarily part of the standard user-visible API.
I've been thinking about the way series of applications can work together, which is what the web.wsgi.environment code is about. Perhaps it would be better to specify the application name in web.wsgi.environment (which is more to do with configuration) so that the web.wsgi.session and web.wsgi.auth objects all use the same application name and then the manager becomes more redundant because a store for the particular application is already created.
web.wsgi.cgi: is this safe when a piece of middleware changes QUERY_STRING or otherwise rewrites the request? You can test for this by saving the QUERY_STRING that you originally parsed alongside the resulting FieldStorage, and then reparsing if they don't match. You can even test for matching with "is", since you're really checking for modifications instead of equality. The same should be possible for wsgi.input and POST requests.
The web.wsgi.cgi module actually builds the FieldStorage from the environ dictionary, not QUERY_STRING so this should mean that middleware can do what it likes and the underlying middleware and application will respond to the changes.. is this not a good way of doing it?
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?
Thanks again for your comments Ian, much appreciated.
James -- James Gardner 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
