You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2001/01/31 17:11:15 UTC
AddOutputFilter enhancement
I'm thinking of enabling AddOutputFilter to take a mime type thusly:
AddOutPutFilter INCLUDES .shtml
and perhaps
AddOutputFilter INCLUDES .shml WAPFILTER .wap, etc.
Here is the problem (if you agree it is a problem) I am trying to solve. I
added AddOutputFilter INCLUDES to my top level directioy and turned on Options
+Includes. Apache 2.0 today will do SSI parsing on all static files served. I
would like to be able to control this behavious more finely (as you could in
Apache 1.3) by restricting only files with .shtml extensions to SSI parsing.
Bill
Re: AddOutputFilter enhancement
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Bill,
Why not use a files container instead? I just tested using
<Files ~ "\.shtml">
AddOutputFilter INCLUDES
</Files>
and it works great. Performance for .html files increases a bunch
while performance for .shtml files is not harmed.
You can also use the regex versions to specify "\.(shtml|WAPFILTER|
.wap|.etc)" for the extended option that you referenced.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: AddOutputFilter enhancement
Posted by rb...@covalent.net.
> > Can't you do that with <Files...>?
> >
>
> Thank you Paul and Ben. Suggestion withdrawn.
Can I suggest that you not withdraw the suggestion? Joshua Slive and I
had this conversation on list a while ago, and he hates the current
setup. I personally agree. I would like to see a lot more control with
regard to which filters are enabled. I have already sent an e-mail
detailing how I would like to see it done, and I am very interested in
other people's opinions.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: AddOutputFilter enhancement
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Bill Stoddard wrote:
> >
> > I'm thinking of enabling AddOutputFilter to take a mime type thusly:
> >
> > AddOutPutFilter INCLUDES .shtml
> >
> > and perhaps
> >
> > AddOutputFilter INCLUDES .shml WAPFILTER .wap, etc.
> >
> > Here is the problem (if you agree it is a problem) I am trying to solve. I
> > added AddOutputFilter INCLUDES to my top level directioy and turned on
Options
> > +Includes. Apache 2.0 today will do SSI parsing on all static files
served. I
> > would like to be able to control this behavious more finely (as you could
in
> > Apache 1.3) by restricting only files with .shtml extensions to SSI
parsing.
>
> Can't you do that with <Files...>?
>
Thank you Paul and Ben. Suggestion withdrawn.
Bill
Re: AddOutputFilter enhancement
Posted by Ben Laurie <be...@algroup.co.uk>.
Bill Stoddard wrote:
>
> I'm thinking of enabling AddOutputFilter to take a mime type thusly:
>
> AddOutPutFilter INCLUDES .shtml
>
> and perhaps
>
> AddOutputFilter INCLUDES .shml WAPFILTER .wap, etc.
>
> Here is the problem (if you agree it is a problem) I am trying to solve. I
> added AddOutputFilter INCLUDES to my top level directioy and turned on Options
> +Includes. Apache 2.0 today will do SSI parsing on all static files served. I
> would like to be able to control this behavious more finely (as you could in
> Apache 1.3) by restricting only files with .shtml extensions to SSI parsing.
Can't you do that with <Files...>?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: AddOutputFilter enhancement
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> Sorry, but I can`t type any more on this crappy connection
>
At ApacheCon in London, we had maybe 20 folks connected to an Airport which was connected to a 56k
dial-up. It couldn't be
-that- bad :-)
Re: AddOutputFilter enhancement
Posted by Joshua Slive <sl...@finance.commerce.ubc.ca>.
On Sat, 3 Feb 2001, Ben Laurie wrote:
> > > Oh, I see ... why is this better than <Files...>?
> >
> > Because I got yelled at when I said to use <Files...>. :-) I was just
> > trying to make people happy.
>
> No-one's yelling about using <Files...> now - in fact, I see only
> agreement.
>
Sorry, I`m just dropping in on this discussion for a second, and then I`ll
be disconnected again for a couple days.
I don`t have any problem with the 'files' type interface, but I should
note that it is not how the rest of the Apache configuration works. In
particular, most configuration of meta-information for files is performed
by designating `extensions`. Extensions have a particular syntax, and
they are not the same as the regex being discussed. (ie, they do not have
to be at the absolute end of the filename, because they could be followed
by other extensions with further meta-information.)
My biggest concern is that AddOutputfilter go away, because it conflicts
baddly with the other Add... type directives. If I was designing the
replacement, I would use something as close as possible to the
AddHandler, Sethandler syntax that already exists. Please don`t make up
some new syntax without a very good reason.
Sorry, but I can`t type any more on this crappy connection
Joshua.
Re: AddOutputFilter enhancement
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > > > 1) SetupFilterStack Stack_name filter1 filter2 etc
> > > > > 2) AddFilterStack Stack_name extension1 extension2 etc
> > > > > 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
> > > >
> > > > This doesn't mean anything to me - would you like to add some
> > > > explanation to your explanation?
> > >
> > > The idea is to clean up the interface a bit. Basically, directive #1
> > > would define a filter stack, which could then be used in the other
> > > two. The other two directives are basically just like AddType and
> > > SetType, except instead of associating a mime-type with an extension or a
> > > handler, it associates a defined filter stack with either a mime-type or
> > > an extension.
> >
> > Oh, I see ... why is this better than <Files...>?
>
> Because I got yelled at when I said to use <Files...>. :-) I was just
> trying to make people happy.
No-one's yelling about using <Files...> now - in fact, I see only
agreement.
> > I have to say I don't like the idea of associating with mime-types,
> > since those are related to the end product, and hence are likely not to
> > be unique to a particular filter stack - or did you mean to match
> > handlers, really?
>
> I guess handlers.
Which makes AddFilterStack redundant already (do AddHandler and
SetFilterStack instead). Not that I'm advocating this approach at all
:-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: AddOutputFilter enhancement
Posted by rb...@covalent.net.
> > > > 1) SetupFilterStack Stack_name filter1 filter2 etc
> > > > 2) AddFilterStack Stack_name extension1 extension2 etc
> > > > 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
> > >
> > > This doesn't mean anything to me - would you like to add some
> > > explanation to your explanation?
> >
> > The idea is to clean up the interface a bit. Basically, directive #1
> > would define a filter stack, which could then be used in the other
> > two. The other two directives are basically just like AddType and
> > SetType, except instead of associating a mime-type with an extension or a
> > handler, it associates a defined filter stack with either a mime-type or
> > an extension.
>
> Oh, I see ... why is this better than <Files...>?
Because I got yelled at when I said to use <Files...>. :-) I was just
trying to make people happy.
> I have to say I don't like the idea of associating with mime-types,
> since those are related to the end product, and hence are likely not to
> be unique to a particular filter stack - or did you mean to match
> handlers, really?
I guess handlers.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: AddOutputFilter enhancement
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > IMHO, a complete re-org of the filter directives is required. I believe I
> > > have outline this on the list before, but I will explain it more now.
> > >
> > > This is a three directive combination.
> > >
> > > 1) SetupFilterStack Stack_name filter1 filter2 etc
> > > 2) AddFilterStack Stack_name extension1 extension2 etc
> > > 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
> >
> > This doesn't mean anything to me - would you like to add some
> > explanation to your explanation?
>
> The idea is to clean up the interface a bit. Basically, directive #1
> would define a filter stack, which could then be used in the other
> two. The other two directives are basically just like AddType and
> SetType, except instead of associating a mime-type with an extension or a
> handler, it associates a defined filter stack with either a mime-type or
> an extension.
Oh, I see ... why is this better than <Files...>?
I have to say I don't like the idea of associating with mime-types,
since those are related to the end product, and hence are likely not to
be unique to a particular filter stack - or did you mean to match
handlers, really?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: AddOutputFilter enhancement
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> The idea is to clean up the interface a bit. Basically, directive #1
> would define a filter stack, which could then be used in the other
> two. The other two directives are basically just like AddType and
> SetType, except instead of associating a mime-type with an extension
> or a handler, it associates a defined filter stack with either a
> mime-type or an extension.
My initial impression is that this is excessively baroque and
will not simplify the configuration at all. However, I will
reserve judgement for now.. first impressions are *not* always
the correct ones. :-)
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: AddOutputFilter enhancement
Posted by rb...@covalent.net.
> > IMHO, a complete re-org of the filter directives is required. I believe I
> > have outline this on the list before, but I will explain it more now.
> >
> > This is a three directive combination.
> >
> > 1) SetupFilterStack Stack_name filter1 filter2 etc
> > 2) AddFilterStack Stack_name extension1 extension2 etc
> > 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
>
> This doesn't mean anything to me - would you like to add some
> explanation to your explanation?
The idea is to clean up the interface a bit. Basically, directive #1
would define a filter stack, which could then be used in the other
two. The other two directives are basically just like AddType and
SetType, except instead of associating a mime-type with an extension or a
handler, it associates a defined filter stack with either a mime-type or
an extension.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: AddOutputFilter enhancement
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> IMHO, a complete re-org of the filter directives is required. I believe I
> have outline this on the list before, but I will explain it more now.
>
> This is a three directive combination.
>
> 1) SetupFilterStack Stack_name filter1 filter2 etc
> 2) AddFilterStack Stack_name extension1 extension2 etc
> 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
This doesn't mean anything to me - would you like to add some
explanation to your explanation?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: AddOutputFilter enhancement
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Wednesday, January 31, 2001 12:50 PM
> > IMHO, a complete re-org of the filter directives is required. I believe I
> > have outline this on the list before, but I will explain it more now.
> >
> > This is a three directive combination.
> >
> > 1) SetupFilterStack Stack_name filter1 filter2 etc
> > 2) AddFilterStack Stack_name extension1 extension2 etc
> > 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
> >
>
> Isn't the Files directive was a pretty elegant way to accomplish the same
> thing w/o adding new directives? All you need is to associate a set of
> filters (and a load order) with a particular mime type/file extension (which
> for our purposes are synonymous). The Files directive seemed to enable that
> quite nicely unless I am missing some function that your proposal enables that
> you cannot do today.
I think I see where Ryan and Joshua are going with this. What if we actually
created a <Mime-Type > block structure to pull these all together, or configure
the FilterStacks using their own block format?
This would make things as legible as possible, group very simple and readable
directives into a group, and prevent us from being too repetitive in what will
become pretty complex configurations.
Bill
Re: AddOutputFilter enhancement
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> IMHO, a complete re-org of the filter directives is required. I believe I
> have outline this on the list before, but I will explain it more now.
>
> This is a three directive combination.
>
> 1) SetupFilterStack Stack_name filter1 filter2 etc
> 2) AddFilterStack Stack_name extension1 extension2 etc
> 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
>
Isn't the Files directive was a pretty elegant way to accomplish the same
thing w/o adding new directives? All you need is to associate a set of
filters (and a load order) with a particular mime type/file extension (which
for our purposes are synonymous). The Files directive seemed to enable that
quite nicely unless I am missing some function that your proposal enables that
you cannot do today.
Bill
Enhancements; directives v.s. blocks
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Wednesday, January 31, 2001 12:27 PM
> IMHO, a complete re-org of the filter directives is required. I believe I
> have outline this on the list before, but I will explain it more now.
>
> This is a three directive combination.
>
> 1) SetupFilterStack Stack_name filter1 filter2 etc
> 2) AddFilterStack Stack_name extension1 extension2 etc
> 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
Agreed that all of these make some sense.
But I'd really like to see the <Files>-style contexts expanded. The <Files>
workaround to Bill's question is the right one. I believe block-style config
of complex structures makes much more sense than too many one liners that
end up scattered throughout the config.
Let me bend this argument the other way.
Mr. Stoddard is rightly concerned that stating C:/server/htdocs/foo/bar/bash
will potentially be 5-6 stat calls even with .htaccess overrides disabled.
By taking down the stat's (since we do them on startup) for C:/server/htdocs
trims all but three of the stats.
Some argued we ought to cache the C:/server/htdocs/foo/bar/bash, but doing so
using the Alias directive has issues according to Ken.
We must stat and case-correct foo, bar, and bash. But I'm working up a patch
to accept DocumentRoot in the context of a location. Assuming we cache what
we need to, try this on for size.
<Location /foo/bar>
DocumentRoot C:/server/htdocs/foo/bar
</Location>
Now... we have no case insensitivity problem (Location is always case sensitive).
/Foo/Bar/Bash takes three stats (it misses the location match, as expected).
/foo/bar/bash takes one stat. bash. We cached the DocumentRoot so we are really
certain the path was correctly typed.
The magic for security? Location is both it's own alias and security (knowing
the user would -never- put a more-secure entity underneath an unsecured entity,
right :-?) No abstraction about why the security in a location block wasn't
applied to an alias.
The more of these _many_directives_ we can roll into block-model constructs,
the easier the httpd.conf file is for humans to parse and find their own errors.
Bill
Re: AddOutputFilter enhancement
Posted by Joshua Slive <sl...@finance.commerce.ubc.ca>.
On Wed, 31 Jan 2001 rbb@covalent.net wrote:
>
> IMHO, a complete re-org of the filter directives is required. I believe I
> have outline this on the list before, but I will explain it more now.
>
> This is a three directive combination.
>
> 1) SetupFilterStack Stack_name filter1 filter2 etc
> 2) AddFilterStack Stack_name extension1 extension2 etc
> 3) SetFilterStack Stack_name mime-type1 mime-type2 etc
>
I'm not sure where people are getting this "mime-type" stuff from. Apache
1.3 has been leaning away from setting anything based on mime-type. I
believe that the "SetFilterStack" above should just take the "Stack_name"
and apply it to the current config context (eg. <Files>).
In any case, there seems to be a desire from those posting to move away
from the complexity suggested by Ryan. The only real reason we need this
complexity is if we want to closely resemble the way configuration
directives in 1.3 work.
Let me suggest the following instead:
Just rename AddFilter to SetFilter and keep all the current functionality.
Reason:
"AddFilter" is clearly a mistake because all the current "Add..."
directives (AddHandler, AddType, etc) map to extensions. On the other
hand, "Set..." directives apply to everything in the current context.
So, extension mapping could then be implemented as something like
<FilesMatch "\.ssi($|\.)">
SetFilter INCLUDES CACHE GZIP
</FilesMatch>
Note that the regex is not all that simple, because it needs to deal with
cases of multiple extensions, and it needs to exclude things like
file.ssis. This is the reason that we may, sometime in the future,
want to add a AddFilter directive. For now, my main concern is just
getting a reasonable interface so that it can be documented.
Joshua.
Re: AddOutputFilter enhancement
Posted by rb...@covalent.net.
IMHO, a complete re-org of the filter directives is required. I believe I
have outline this on the list before, but I will explain it more now.
This is a three directive combination.
1) SetupFilterStack Stack_name filter1 filter2 etc
2) AddFilterStack Stack_name extension1 extension2 etc
3) SetFilterStack Stack_name mime-type1 mime-type2 etc
Ryan
On Wed, 31 Jan 2001, Bill Stoddard wrote:
> I'm thinking of enabling AddOutputFilter to take a mime type thusly:
>
> AddOutPutFilter INCLUDES .shtml
>
> and perhaps
>
> AddOutputFilter INCLUDES .shml WAPFILTER .wap, etc.
>
> Here is the problem (if you agree it is a problem) I am trying to solve. I
> added AddOutputFilter INCLUDES to my top level directioy and turned on Options
> +Includes. Apache 2.0 today will do SSI parsing on all static files served. I
> would like to be able to control this behavious more finely (as you could in
> Apache 1.3) by restricting only files with .shtml extensions to SSI parsing.
>
> Bill
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------