On Nov 9, 10:17 am, "Randy Pearson" <[EMAIL PROTECTED]> wrote: > Hi. First time caller. We're studying WSGI and Pylons as a likely > environment to which to port existing applications and framework. In our > current environment, we often have 2 or more applications running under a > single process, where an "app manager" object sequentially offers the > request to each application, until one claims and handles it. > > There is an existing WSGI middleware piece named Cascade that appears to > work similarly, and could be a candidate approach; however, it uses 404 > responses from the applications as its signal to keep looking. In our > design, 404 responses have a different meaning: that the application has > accepted the URL pattern as being its own, and is deliberately stating that > a specific document or resource is not found. Thus we would specifically not > want to pass the request on to other apps when a 404 is returned. > > Is this "404 messaging" approach really needed? Or more specifically, does a > WSGI application need to respond at all? Maybe instead it simply never calls > the start_response callable and just returns None. If the app manager could > then examine whether start_response was called, and use that information to > decide whether to pass on to the next app. (If no app starts a response, the > app manager then issues the 404.)
The start_response() must be called with a valid HTTP status before a WSGI application can return. The cascading of calls whereby they can indicate they decline to handle the request is something that can be done in Apache/mod_python, but there is no direct equivalent in WSGI. The closest you can get is to use 404 or some other HTTP status. The Cascade implementation probably came about because I was querying about the same sort of functionality back in 2005 and a similar example was presented as the WSGI way of doing it. See: http://mail.python.org/pipermail/web-sig/2005-July/001519.html http://mail.python.org/pipermail/web-sig/2005-July/001525.html I too see the ability to cascade as possibly useful, but that one has to overload on the return status as not being ideal. I have some ideas of how to otherwise handle it, but have never had time to sit down and expand on them and see how practical it may be. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
