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.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
