httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Random Filter Syntax observations...
Date Thu, 06 Sep 2001 07:06:18 GMT
----- Original Message ----- 
From: "barries" <>
To: <>
Sent: Thursday, May 17, 2001 1:30 PM
Subject: [PATCH] add Push...Filter, alter Set...Filter

> This patch makes Set...Filter replace all configed filters and
> introduces Push...Filters to provide the current Set...Filter
> functionality.

Clearly - there are other users out there that also expect Set to override
another set of filters.  Unfortunately, I don't know that we can wipe out
the entire filter stack, but we can certainly override any other Set...Filter
directive in a parent container for a child container.

Push...Filters is a very interesting idea that warrents more consideration,
especially in terms of subrequests (Push/Pop could be a great idea.)

----- Original Message ----- 
From: "Ryan Bloom" <>
Sent: Monday, September 03, 2001 10:19 PM
Subject: Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

> On Monday 03 September 2001 18:58, William A. Rowe, Jr. wrote:
> > At this point, I'm strongly in favor of all usual mappings
> > (Add/SetOutputFilter) occuring in the mime_types phase.  When the
> > insert_filters hook is invoked, your module can look at the filter stack,
> > and rearrange it however you like.  Of course, others in that hook chain
> > could do the same, so it makes sense to only change what you absolutely
> > must.
> No, allowing random modules to re-order the filter chain is just asking for
> trouble, and it removes any hope of allowing the admin to order it correctly
> for their site.

Actually, _many_ filters are going to be better able to cope with their proper
ordering than a typical Administrator.  If you mean -You-, one of the five 
gurus of filtering, then yes, it might get in -Your- way.  The average admin
will be filling the bugs. database, c.i.w.s. forums and every vendor's tech

----- Original Message ----- 
From: "Ryan Bloom" <>
Sent: Monday, September 03, 2001 7:03 PM
Subject: Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

> On Monday 03 September 2001 15:42, Rasmus Lerdorf wrote:
> > There should be a way to specify ordering of the content handlers in the
> > stack.
> There is.  In fact, there are TWO ways to configure this.  The first way, is
> to do it in the config file.  If you do:
> AddOutputFilter INCLUDES PHP

This works, until the admin combines multiple mechanisms to insert filters.  But
by the very nature of filters, some make more sense by filename, some by type,
and some by container.  A few might make sense in any of these schemas.

> Then mod_include will always be run before mod_php.  the second way is
> for module authors to do this.  Each module has an insert_filters phase.  By
> ordering the insert_filters phase, you can order which filter is called when.

No argument there.

----- Original Message ----- 
From: "Greg Stein" <>
To: <>
Sent: Monday, September 03, 2001 6:34 AM
Subject: Re: cvs commit: httpd-2.0/modules/http mod_mime.c

> On Sun, Sep 02, 2001 at 09:05:50PM -0700, Justin Erenkrantz wrote:
> > 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.  

That won't be a problem, rethinking things.

It will have to go through a wildcard list as a seperate step (before? after?  I don't
have a good answer).  But using SetOutputFilterByType again for the same text/* or 
text/plain type in a nested container _will_ override the prior setting.

> > > Yes... please read mod_mime.html.  AddSomething is not additive, and can't
> > > The server config is often a nightmare to grok as things stand today.  Don't
> > > things harder by absusing fairly consistant definitions such as AddSomething
> > > 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.

As a user?  You aren't a user, you are a project member.  The rest of the world hasn't
seen filters in Apache.  We have to be very careful here not to confuse the world of
Unix admins, before they begin perceiving Apache as just as presumptive as IIS.  They
want to tell the server what to do, not the other way around.

> > > So the inner needs AddOutputFilter FOO;BAR html - as of today.  I suggested
> > > entire +|- syntax as well, it was somewhat booed since existing +|- syntaxes
> > > 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).

It's clear an entire set of RemoveOutputFilter/RemoveOutputFilterByType etc. may be
required.  Let's finish this and see how far from being 'predictable'.

> > > 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
> I'm in complete agreement with Justin on this one.
> "Add" says "add" to me. And filters *are* additive.

That is _not_ the syntax of mod_mime.  If you use AddCharset in _different_
containers, the most specific container wins.  That's how all Apache directives work,
you can't start flipping concepts on administrators.  If you want to add a new 
directive like Inject or Insert, then fine, but you can't piggy new parsing rules
on already well-defined and predictable directive families like Set or Add.

> I wouldn't agree with Joshua's comments about tossing filter directives and
> rely on each module to provide their own (how would you order them?), but I
> think his meta-comment about "this stuff is confoozled" applies. A step back
> and a rethink is probably necessary, rather than poking and prodding at the
> various config directives.

Right on, and that's the thought I wanted to close this message with.

I'll revert the patch that misused the Add directive.  Now we can go to square one
and ask what on earth we are asking, exactly.  We don't want to overwhelm the casual
user of Apache.  We don't want to require a GUI to 'understand' what Apache has done
to them.


View raw message