httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Random Filter Syntax observations...
Date Sat, 08 Sep 2001 05:19:13 GMT
From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Sent: Thursday, September 06, 2001 5:59 PM


> On Thu, Sep 06, 2001 at 05:43:53PM -0700, William A. Rowe, Jr. wrote:
> > Because from context to context you mean to change the server config.  What
> > works in one Location doesn't work for another, what is good for one directory
> > isn't good for another.
> > 
> > You need to be able to replace those configs, if these are piled on, after 
> > a sufficent number, the user won't be able to untangle where that filter
> > came in to the picture.  I believe Add/Set will prove more generally useful
> > than the new Insert/(Delete?) directive, but I'm willing to be proven wrong.
> 
> Well, I think filters should be inherited from a higher-level directory.  
> Or, at the very least, allow a syntax that has that (such as 
> InsertOutputFilter).

That's what I'm offering, an entirely alternate syntax to do what you are suggesting,
while preserving the Set/Add semantic.

> When you say {Set|Add}OutputFilter, you clobber the filter chain.

That's a gross misstatement.  Set|Add will _not_ replace the filter chain.  They
select a specific set of filters that is appropriate for the resource.  For example,

SetOutputFilter Gzip             <<< only replaces a prior SetOutputFilter
AddOutputFilter Includes .shtml  <<< only replaces a prior Add... for .shtml
AddOutputFilter UnFoo    .foo     <<< only replaces a prior Add... for .foo

So the end result of something.shtml.foo would insert Gzip, Includes, and UnFoo.
The big issue is ordering, how do we properly untangle these.  We would place the
.shtml filter before .foo (filename extension order) but where should Gzip appear,
after or before the other Add...Filter syntax???

But it's not fair to suggest this syntax 'clobbers' anything.  It replaces some
settings that might not be appropriate, in an unambigious way.

> When you say InsertOutputFilter, you tack on that filter to the already
> assembled chain (probably to the end).

That's fine.  I'd suggest we even want InsertOutputFilter to have a positional
syntax, to allow you to Insert before/after another filter (if it's present.)

> > I'm -1 on eliminating Set/AddOutputFilter syntax.  We can suppliment with Insert
which 
> > has the properties you desire.  As for Remove, that's the converse of the mime Add

> > directives, so we need a synonym that reflects new Insert directives (Delete?).
> 
> Supplementing works.  I'm the converse of you - I don't think many
> people will use Set/AddOutputFilter as you describe, but I'm willing
> to be proven wrong.  (Delete works for me as the converse of Insert,
> but we may get user confusion if we have two commands that remove a
> filter from the chain - I think only one is really necessary...)

What are you talking about?  RemoveOutputFilter .shtml DOESN'T REMOVE A FILTER!!!
It eliminates the association between .shtml and whatever filters had been otherwise
configured with AddOutputFilter somefilters .shtml.  It works _exactly_ like every
other AddSomething/RemoveSomething for mime association.

Notice that your DeleteFilter does exactly that, it would delete a filter added by
ANY METHOD :)  So that's pretty unambigious.  DeleteOutputFilter Includes would
take out that filter if it was added by AddOutputFilter, AddOutputFilterByType,
SetOutputFilter, or InsertOutputFilter.  Pretty powerful, very useful.

Bill


Mime
View raw message