[Web-SIG] Re: WSGI and Configuration
ianb at colorstudy.com
Mon Nov 15 06:40:02 CET 2004
Alan Kennedy wrote:
> So ISTM that discussing configuration of middleware stacks is partly a
> discussion about an URI->object resolution mechanism, i.e. mapping an
> URI hierarchy to a tree of python objects. The shape of the python
> object tree may be either
> 1. Static, i.e. built at container start-time, and where the container
> selects target application objects based on URI components in each request.
Well, this doesn't preclude dynamic either. Unless the server requires
that PATH_INFO be empty, the application always has the option to
delegate further. All WSGI applications should look the same to the
server/gateway, regardless of if they are middleware of terminal
> 2. Dynamic, where the application objects themselves get to decide where
> the request is routed next, quixote-style. But it is still the
> container's job to actually resolve/import the next object down in the
> So I think we're definitely in framework-land.
> I'm beginning to think that maybe the concept of framework-agnosticism
> doesn't fit with the concept of middleware stacks. A mechanism for
> constructing middleware stacks is a framework, an instance of a
> middleware stack is an application/hierarchy-of-nested-applications.
> Maybe it's time to start thinking about WSGI Layer 2:- The middleware
You mean standardizing middleware, or extending WSGI? I'm comfortable
with what WSGI allows, I don't think it needs to be extended at all. As
for standardizing middleware, I think that's a separate standard by a
separate name, and we'll need some implementation experience under our
> Or maybe we need to find other middleware examples besides
> authentication and session handling, which are the two things most often
> "pre-decided" with many servers and almost any web programming framework
> in any language (because they're such a pain). Maybe they are special
> cases that need to be considered separately anyway?
Well, here's the middleware I'm using:
* cgitb_catcher, catches unhandled exceptions and formats a response
* dispatch, a crappy URL parser; only interesting in that it also can
add middleware via the URL (useful for testing)
* gzipper, a gzip-encoding middleware
* httpexceptions, which catches specific exceptions (e.g.,
HTTPTemporaryRedirect) and turns them into proper responses. Probably
the least WSGI-ish of these middlewares.
* lint, a standard-verifying middleware that doesn't otherwise effect
valid requests or responses
* recursive, a middleware that allows for recursive calls into the
application. It's limited to calls below its position in the middleware
stack. This was necessary for implementing some Webware APIs. And it
seems pretty useful too. It allows for forwarding (passing control) and
inclusion (doing a recursive call).
* session, a session handler
* urlparser, a URL parsing middleware. It parses the first part of
PATH_INFO, and finds the next resource. If the next resource is a
directory, it creates a new URLParser and passes control to it; it also
has hooks for adding other file->application converters.
* webkit.wsgiwebkit.webkit, which just takes a whole bunch of these and
puts them together.
The only thing that has been very confusing for me is handling
exceptions, and most of these don't do so very well.
I think sessions would be easy to standardize, because they are pretty
boring. You store stuff, later on you get it back. There's lots of
possible features (e.g., storing in a database), but the API is pretty
stable and understood irregardless of those features. Authentication is
a little harder, but I think it's not too bad if you don't take on too
much at once. I think it's only so complicated because authorization
often gets folded into authentication. Authentication sources (e.g.,
LDAP) should be kept out of the middleware; instead a simple and neutral
API for authentication sources should be used.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG