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
-~----------~----~----~----~------~----~------~--~---

Reply via email to