Ian Bicking wrote .. > There's several conventions that could be used for trying applications > in-sequence. For instance, you could do something like this (untested) > for delegating to different apps until one of them doesn't respond with > a 404: > > class FirstFound(object): > """Try apps in sequence until one doesn't return 404""" > def __init__(self, apps): > self.apps = apps > def __call__(self, environ, start_response): > def replacement_start_response(status, headers): > if int(status.split()[0]) == 404: > raise HTTPNotFound > return start_response(status, headers) > for app in self.apps[:-1]: > try: > return app(environ, replacement_start_response) > except HTTPNotFound: > pass > # If the last one responds with 404, so be it > return self.apps[-1](environ, start_response) > > > Anyway, people may feel that this is totally contrary to what WSGI is > > all about and > > not relevant and that is fine, I am at least finding it an interesting > > idea to > > play with in respect of mod_python at least.
As far as using 404 to indicate this, I had thought of that, but it then precludes one of those applications actually raising that as a real response. I often return NotFound as opposed to Forbidden when access is to files such as ".py" files. Return forbidden still gives a clue as to what implementation language is used where as returning not found doesn't. I do this, perhaps in a misguided way, as by not exposing how something is implemented, I feel it makes it just a bit harder for people to work out how to breach your security. :-) If one was going to use a specific error code to indicate next application object should be tried, maybe it might be more appropriate to use 303 (See Other) with there being no redirect URL specified. Ie., something that doesn't necessarily overlap with something that might be valid for a application object to do. > It's very relevent, at least in my opinion. This is exactly the sort of > architecture I've been attracted to, and the kind of middleware I've > been adding to Paste. The biggest difference is that mod_python uses an > actual list and return values, where WSGI uses nested function calls. To say that mod_python uses an actual list is only really true at the level of Apache configuration where one defines the PythonHandler directive and can specify multiple handlers to run in succession. Most people would only have the one. At the level I am working where I use "Handlers()", not a part of mod_python itself, I am using both sequences of handlers as well as recursive nesting. The "IfLocationMatches()" object in my examples was wrapping the "NotFound()" object, but it could equally have wrapped a "Handlers()" or another "If" object, which in turn wraps lower level objects. Even the "PythonModule()" object wrapped objects indirectly, they just happen to be loaded at run time much like the URLParser example for Paste. Thus I am using both lists and nested callable objects in the way of wrappers. WSGI seems to focus mainly on the latter of using only nested calls in all the examples I have seen, although you do show above one way perhaps of having a lineal search for an application object. Anyway, the point I was trying to make was that to me, the lineal search through a list of handlers (or application objects) seems to be an easier way of dealing with things in some cases and looks simpler in code than having a long nested chain of objects, yet WSGI doesn't seem to make any real use of that approach to composing together middleware components. I'll leave it at that for the moment. I guess I'll just have to show whether one way works better and is easier to understand than the other by way of example at some point. :-) Thanks for the response. Graham _______________________________________________ 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