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

[Alice Bevan–McGregor]

Ian,

> It's not clear to me how this can be composed or abstracted.

Filters themselves have no knowledge of the applicaiton, in a similar 
vein to middleware not knowing if the next layer in the onion skin is 
the final application, or another bit of well-behaved middleware, 
except that filters do not get a reference to an "inner" application at 
all.  (They are linear, not nested.)

> (Most output filters also need the request.)

You are quite correct; I'll upate the PEP.  marrow.server.http already 
passes environ to egress filters in addition to the status_bytes, 
headers_list, body_iter data.

> But while it handles the input filter case, it doesn't try to 
> generalize this or move application composition into the server.

A large proportion of the filters I was able to imagine are 
conditionless: there would be no "path" within your application 
(controller or otherwise) that would need to modify the majority of 
them.  As an example, egress compression.  (And even then, my example 
egress compression filter offers a documented mechanism to disable it 
on a per-request basis.)

> An application is an application and servers are imagined but not 
> actually concrete.

Could you elaborate?  (Define "concrete" in this context.)

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

	— Alice.