httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Slive <jos...@slive.ca>
Subject Re: Broken SetOutputFilter/SetInputFilter semantics
Date Wed, 29 Aug 2001 19:52:14 GMT

[warning: annoying rambling to follow]

On Wed, 29 Aug 2001, William A. Rowe, Jr. wrote:

>   I'm suggesting, today, that we support the following syntax for all these directives;
>
> {Add|Remove}{Input|Output}Filter [+|-]foo[;[+|-]bar...] ext [ext...]
>
> {Add|Remove}{Input|Output}FilterByType [+|-]foo[;[+|-]bar...] [mime-type]
>
> Set{Input|Output}Filter [+|-]foo[;[+|-]bar...]   OR  UnSet{Input|Output}Filter
>
>   Again, UnSetFooFilter takes no args, it undoes the SetFilter, that's all.  It has no
> effect on the Add/RemoveFooFilter stuff.  Apache will get an UnSetHandler that does the
> very same thing.

It's great you are addressing this problem, since it will be an obvious
source of user annoyance.  But I don't know about your solution.

One problem with it is that the +|- syntax is confusing.  We have this for
Options, and I almost never see it used correctly.  It is especially bad
because it makes the final configuration very dependent on the
configuration processing order, which almost nobody understands
completely.

Another issue is the ordering that the filters are applied. If I say
AddOutputFilter decompress .gz
AddOutputFilter includes .shtml
how do we decide which filter comes first?  The config file order of the
directives? The order of the extensions?  (Ouch!)
The same question applies to your syntax above.  The ordering of
the filters is rather non-obvious after several
SetOutputFilter +foo;-bar
SetOutputFilter +bar;-foo;+foobar
rounds.

A third problem is that I don't believe Apache 2.0 supports argument-less
directives.

Unfortunately, I can't come up with a great alternative.
A couple ideas:

1. Add an {input|output}FilterOrder directive which specifies the order
of filter processing.

2. Have Set{Input|Output}Filter take the special filter name "none" which
clears the filter stack.  (I believe we already have a similar, though
undocumented, handler that just forces processing back to the core.)

Then you could do things like

<directory /foo>
SetOutputFilter includes
</directory>

<directory /foo/bar>
SetOutputFilter decompress
OutputFilterOrder decompress includes
</directory>

<directory /foo/bar/baz>
SetOutputFilter none
SetOutputFilter includes
</directory>

I admit that last one is slightly non-obvious, but I don't think it is any
worse than the alternatives.

A possible alternative would be a ClearOutputFilter directive which
can remove a specific list of filters from the stack after they
have been set by SetOutputFilter.  (The better syntax would be
RemoveOutputFilter, but that is already taken.)



Joshua.


Mime
View raw message