You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2005/06/19 18:33:14 UTC
Removing AddOutputFilterByType
AddOutputFilterByType has always been problematic. I see there's another bug
report this month arising from it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33499
Since the purpose of this directive is now available from mod_filter, does
anyone object if I simply yank AddOutputFilterByType from 2.1?
I've hacked a quick patch just to remove it. If people are happy with it,
I'll test it and commit, and add a note to the docs about replacing it.
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by Nick Kew <ni...@webthing.com>.
On Sunday 19 June 2005 19:57, Nick Kew wrote:
> But as a more general point, if there's something AddOutputFilterByType
> does that mod_filter doesn't do - or complicates doing
Bah. I was going to say something about if [...] then mod_filter wants
reviewing. Then I stopped, but didn't chop out the unfinished sentence.
Sorry folks.
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by Nick Kew <ni...@webthing.com>.
On Sunday 19 June 2005 17:47, William A. Rowe, Jr. wrote:
> Uhm, yes. Most definately object. Trying to map ever type
> that resolves back to, say, text/*, or text/html, would be
> an unnecessary pain.
How is a regexp match
FilterProvider textfilter my-filter content-type /^text/
or a substring match
FilterProvider textfilter my-filter content-type $text/
an unnecessary pain?
> I'll look at those reports though, I still have some neurons
> of info about how/why it was implemented; perhaps I can help
> on those PR tickets. After my HTTP Request proxy test cluster
> is done so I'm happy with our solutions to the Watchfire report.
Fairy nuff:-)
But as a more general point, if there's something AddOutputFilterByType
does that mod_filter doesn't do - or complicates doing
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Uhm, yes. Most definately object. Trying to map ever type
that resolves back to, say, text/*, or text/html, would be
an unnecessary pain.
I'll look at those reports though, I still have some neurons
of info about how/why it was implemented; perhaps I can help
on those PR tickets. After my HTTP Request proxy test cluster
is done so I'm happy with our solutions to the Watchfire report.
Bill
At 11:33 AM 6/19/2005, Nick Kew wrote:
>AddOutputFilterByType has always been problematic. I see there's another bug
>report this month arising from it:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=33499
>
>Since the purpose of this directive is now available from mod_filter, does
>anyone object if I simply yank AddOutputFilterByType from 2.1?
>
>I've hacked a quick patch just to remove it. If people are happy with it,
>I'll test it and commit, and add a note to the docs about replacing it.
>
>--
>Nick Kew
Re: Removing AddOutputFilterByType
Posted by Nick Kew <ni...@webthing.com>.
On Tuesday 21 June 2005 06:10, Astrid Keßler wrote:
> at Montag, 20. Juni 2005, Nick Kew wrote:
> > Hmmm. Is it better to have a UI that's openly a little more complex but
> > works as documented, or one that appears simple but has lots of
> > gotchas lurking in ambush? I guess that's an argument for mod_filter
> > implementing AddOutputFilterByType.
>
> First, it's an argument to improve the docs ;)
Not sure about that. Full documentation for AddOutputFilterByType could
become quite mindboggling.
The gotcha that generates most questions is "doesn't work at all in [various
situations, notably a proxy]". ISTR that *is* documented somewhere, but
people don't notice because it's unintuitive.
Add the *ordering* issue (always comes *after* filters configured with other
directives), and it's already more complex to get the mind around than
mod_filter.
Now add the complex interactions that happen in setups involving more than
module, or even within a single module (c.f.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33499 )
and it's not IMO something that can be documented adequately without extensive
self-defeating reference to the code itself.
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by Astrid Keßler <ke...@kess-net.de>.
at Montag, 20. Juni 2005, Nick Kew wrote:
> Hmmm. Is it better to have a UI that's openly a little more complex but
> works as documented, or one that appears simple but has lots of
> gotchas lurking in ambush? I guess that's an argument for mod_filter
> implementing AddOutputFilterByType.
First, it's an argument to improve the docs ;)
Kess
Re: Removing AddOutputFilterByType
Posted by Nick Kew <ni...@webthing.com>.
On Monday 20 June 2005 06:44, Justin Erenkrantz wrote:
> > Since the purpose of this directive is now available from mod_filter,
> > does anyone object if I simply yank AddOutputFilterByType from 2.1?
>
> Why can't AddOutputFilterByType call mod_filter under the hood?
Good point.
Of course it raises issues of filter order that I'd prefer to avoid.
But that's at least less counterintuitive than the existing ordering
with AddOutputFilterByType and [anything else].
> But, from the user's perspective, I think AddOutputFilterByType needs to
> stay and I'm not convinced that mod_filter has a good enough directive
> interface to make it intuitive. -- justin
Hmmm. Is it better to have a UI that's openly a little more complex but
works as documented, or one that appears simple but has lots of
gotchas lurking in ambush? I guess that's an argument for mod_filter
implementing AddOutputFilterByType.
FWIW, it could also do SetOutputFilter, but AddOutputFilter may be
more problematic, in that dispatching on filename/extension needs
thought to avoid introducing another set of problems. But of course
there's no pressing need to change those in the first place.
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On June 19, 2005 5:33:14 PM +0100 Nick Kew <ni...@webthing.com> wrote:
> AddOutputFilterByType has always been problematic. I see there's another bug
> report this month arising from it:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33499
>
> Since the purpose of this directive is now available from mod_filter, does
> anyone object if I simply yank AddOutputFilterByType from 2.1?
Why can't AddOutputFilterByType call mod_filter under the hood?
But, from the user's perspective, I think AddOutputFilterByType needs to stay
and I'm not convinced that mod_filter has a good enough directive interface to
make it intuitive. -- justin
Re: Removing AddOutputFilterByType
Posted by Nick Kew <ni...@webthing.com>.
On Sunday 19 June 2005 17:42, André Malo wrote:
> Is mod_filter capable of something like this:
>
> AddOutputFilterByType INCLUDES httpd/unix-directory
>
> ? I'm personally using that heavily to get SSI into autoindex descriptions.
Yow! You mean httpd/unix-directory - which is most emphatically *not* a
content type - is passing through ap_set_content_type?
To answer your question, mod_filter can dispatch on r->handler, so if handler
gets set to "httpd/unix-directory" then yes. If not, then it would need a
workaround, such as dispatching on text/html and controlling the scope
of that with a FilesMatch or something of that ilk. Or a patch to mod_filter.
--
Nick Kew
Re: Removing AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Nick Kew wrote:
> AddOutputFilterByType has always been problematic. I see there's another
> bug report this month arising from it:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33499
>
> Since the purpose of this directive is now available from mod_filter,
> does anyone object if I simply yank AddOutputFilterByType from 2.1?
Is mod_filter capable of something like this:
AddOutputFilterByType INCLUDES httpd/unix-directory
? I'm personally using that heavily to get SSI into autoindex descriptions.
nd
--
Winnetous Erbe: <http://pub.perlig.de/books.html#apache2>