On Sun, Sep 02, 2001 at 10:49:52PM -0500, William A. Rowe, Jr. wrote:
> Not this way. No other mod_mime variable behaves the way you you are trying.
> I'm not kidding about adding a Set{Input|Output}FilterByType/SetHandlerByType
> so when we ask folks to rely upon mime types, they can actually do so.
And, that's additive?
So, I could do:
SetOutputFilterByType BAR text/*
SetOutputFilterByType FOO text/plain
As a user, I *expect* that both filters are activated.
I think you make it sound like we have to do:
SetOutputFilterByType BAR text/*
SetOutputFilterByType BAR;FOO text/plain
Yuck, yuck, yuck, yuck, yuck. (Did I mention I think this is yucky?)
> Yes... please read mod_mime.html. AddSomething is not additive, and can't be.
> The server config is often a nightmare to grok as things stand today. Don't make
> things harder by absusing fairly consistant definitions such as AddSomething or
> SetSomething. The inner container always overrides the outer.
As a user, I expect that to be additive *in the case of a filter*. I
expect it to override in the other cases - just not this case. You
can't have multiple handlers, but you can certainly have multiple
filters.
> So the inner needs AddOutputFilter FOO;BAR html - as of today. I suggested an
> entire +|- syntax as well, it was somewhat booed since existing +|- syntaxes are
> perceived as confusing. Here, well I think it's necessary.
That's confusing. I think the cleanest way is for it to be additive
(with a RemoveOutputFilter to remove one from a higher level -
ignoring this directive if the filter doesn't exist from a prior
level).
> None of this is addressing filter ordering across commands yet. I said 8 months
> ago we've done an inadequte job of defining the use-filters syntax. I'm saying
> the very same thing today.
Yeah, I expect that the ordering of filter execution isn't going to be
right given the code we have now. -- justin
