It seems to me heavily counterintuitive that mixing ByType directives with anything else means that the ByType filters *always* come last. And that Remove won't affect them, but will affect others.
I think we could get Remove*Filter to also delete the content-type filters.
Indeed. mod_filter addresses this by configuring at the last moment, so any earlier set_content_type()s are irrelevant. I don't suppose it's a panacaea for everything, but I do think it's a significant improvement on what we have.
I'm concerned about the overhead of mod_filter having to check all of its rules each time a filter is invoked. This is why I started to look through the code last night to see how it worked and how invasive it is.
How would you handle the situation when filter #1 sets C-T to be "text/plain" and then filter #2 sets C-T to be "text/html"? And, then mod_deflate needs to be conditionally added (sub-case #1: it needs to be added for 'text/plain'; sub-case #2: it needs to be added for 'text/html'). How and where is it added? Are you inserting dummy filters?
From the user's perspective, it's simply more powerful and flexible. Works with any request or response headers (not just content-type) or environment variables. Gets rid of constraints on ordering, like AddOutputFilterbyType filter always coming after other filters regardless of ordering in httpd.conf.
Example: I have a user who wants to insert mod_deflate in a reverse proxy, but only for selected content-types AND not if the content length is below a threshold. How would he do that with the old filter framework?
I guess I'm not clear what the syntax is (I guess I should go read the docs). I definitely don't want to see the filters be configured like mod_rewrite. It needs to be fairly straightforward, but still fairly simplistic. I don't want to have users have to read a complicated manual or docs to set up filters. KISS.
From a developers perspective, I wrote it for myself, and have at least two other developers using it operationally in their product. Time will tell what others may use it for.
Well, the point by you committing it into our tree is that the rest of us are now responsible for it. That's why I brought up the code style issue: we already have a number of modules that were never fully integrated or reviewed. And, then the person who dropped the code ran away and left the code in a goofy state. (See mod_rewrite, mod_ssl, mod_cache, etc.)
When was that? I made quite a lot of updates to the style towards conforming (like eliminating tabs and realigning some braces) before committing to CVS, but I'm willing to believe I need to look more carefully.
I looked yesterday afternoon (and haven't seen any commits since then). I will say the most distracting parts are the odd spacing (i.e. parenthesis and semi-colons) as well as line spacing. Unfortunately, I get distracted by shiny things such as improper code style such that I can't focus on the code itself. =) -- justin
