[Web-SIG] PEP 444 / WSGI2 Proposal: Filters to suppliment middleware.

[Ian Bicking]

On Tue, Dec 14, 2010 at 12:54 PM, Alice Bevan–McGregor
<alice at gothcandy.com>wrote:

>
>  An application is an application and servers are imagined but not actually
>> concrete.
>>
>
> Could you elaborate?  (Define "concrete" in this context.)


WSGI applications never directly touch the server.  They are called by the
server, but have no reference to the server.  Servers in turn take an app
and parameters specific to there serveryness (which may or may not even
involve HTTP), but it's good we've gotten them out of the realm of
application composition (early on WSGI servers frequently handled mounting
apps at locations in the path, but that's been replaced with dispatching
middleware).  An application wrapped with middleware is also a single object
you can hand around; we don't have an object that represents all of
"application, list of pre-filters, list of post-filters".



>
>  If you handle filters at the server level you have to have some way of
>> registering these filters, and it's unclear what order they should be
>> applied.  At import?  Does the server have to poke around in the app it is
>> running?  How can it traverse down if you have dispatching apps (like
>> paste.urlmap or Routes)?
>>
>
> Filters are unaffected by, and unaware of, dispatch.  They are defined at
> the same time your application middleware stack is constructed, and passed
> (in the current implementation) to the HTTPServer protocol as a list at the
> same time as your wrapped application stack.
>
>
>  You can still implement this locally of course, as a class that takes an
>> app and input and output filters.
>>
>
> If you -do- need "region specific" filtering, you can ostensibly wrap
> multiple final applications in filter management middleware, as you say.
>  That's a fairly advanced use-case regardless of filtering.
>
> I would love to see examples of what people might implement as filters
> (i.e. middleware that does ONE of ingress or egress processing, not both).
>  From CherryPy I see things like:
>
> * BaseURLFilter (ingress Apache base path adjustments)
> * DecodingFilter (ingress request parameter decoding)
> * EncodingFilter (egress response header and body encoding)
> * GzipFilter (already mentioned)
> * LogDebugInfoFilter (egress insertion of page generation time into HTML
> stream)
> * TidyFilter (egress piping of response body to Tidy)
> * VirtualHostFilter (similar to BaseURLFilter)
>
> None of these (with the possible exception of LogDebugInfoFilter) I could
> imagine needing to be path-specific.


GzipFilter is wonky at best (it interacts oddly with range requests and
etags).  Prefix handling is useful (e.g.,
paste.deploy.config.PrefixMiddleware), and usually global and unconfigured.
Debugging and logging stuff often needs per-path configuration, which can
mean multiple instances applied after dispatch.  Encoding and Decoding don't
apply to WSGI.  Tidy is intrusive and I think questionable on a global
level.  I don't think the use cases are there.  Tightly bound pre-filters
and post-filters are particularly problematic.  This all seems like a lot of
work to avoid a few stack frames in a traceback.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20101214/7cf30721/attachment-0001.html>