[Web-SIG] Standardized configuration

[Graham Dumpleton]

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