You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by André Malo <nd...@perlig.de> on 2002/09/15 02:08:45 UTC
Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
* Jeff Trawick wrote:
> What about AddOutputFilterByType? Is that working properly now?
It works at least for me (win32, 2.0.40 tested).
I've attached a patch for core.xml that should match the current HEAD
(of core.c). Please review and feel free to correct the English if
neccessary ;-)
The patch was reviewed and discussed before with Kess.
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* André Malo wrote:
> * Justin Erenkrantz wrote:
>
>> I don't have any easy solutions to this. Well, I do, but it'd
>> require always doing the ap_getword call in the mainline request
>> path (which is how mod_mime does it). That is so beyond awful...
>
> hmm, now I had the time to think a little bit about. You'll find a
> patch attached for the current function in core.c - untested and just
> meant as idea. Feel free to throw it away, if it's not a good idea...
> ;-)
hmm, I have the feeling, my patches are always overlooked ;-)
Don't wanna be pushy, but is there really nothing to say (e.g. what's
wrong with this or so?)
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> I don't have any easy solutions to this. Well, I do, but it'd
> require always doing the ap_getword call in the mainline request
> path (which is how mod_mime does it). That is so beyond awful...
hmm, now I had the time to think a little bit about. You'll find a patch
attached for the current function in core.c - untested and just meant as
idea. Feel free to throw it away, if it's not a good idea... ;-)
> Perhaps we should add a:
>
> apr_status_t ap_filter_rec_parse(apr_pool_t *, ap_filter_rec_t **,
> const char *);
No need to define code twice:
+1.
>> - this ordering doesn't affect the DEFLATE and INCLUDES filter
>> (because of different filter types), right?. If so, they are
>> bad examples for the "filter;filter" notation in general.
>> Perhaps this should be mentioned in the mod_mime docs resp. the
>> filters docs, too...
>
> Correct. But, we really only have two user-visible filters that
> aren't experimental. -- justin
Unfortunately. (did my tests with an ExtFilterDefine ;-)
nd
--
If God intended people to be naked, they would be born that way.
-- Oscar Wilde
Re: Review: AddOutputFilterByType
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 03:16:16AM +0200, André Malo wrote:
> ok, I see the change, but two points:
>
> - AFAICS the filter ordering is still reversed (in contrast to the
> mod_mime definition)?
I don't have any easy solutions to this. Well, I do, but it'd
require always doing the ap_getword call in the mainline request
path (which is how mod_mime does it). That is so beyond awful...
Perhaps we should add a:
apr_status_t ap_filter_rec_parse(apr_pool_t *, ap_filter_rec_t **,
const char *);
which takes a "<filterx>;<filtery>;<filterz>" and appends to the
passed in ap_filter_rec_t (creating one if it isn't NULL). Then,
we can add the ugly code to do insertion at the end of
ap_filter_rec_t in one central place and switch the core and
mod_mime to use this function.
> - this ordering doesn't affect the DEFLATE and INCLUDES filter
> (because of different filter types), right?. If so, they are
> bad examples for the "filter;filter" notation in general.
> Perhaps this should be mentioned in the mod_mime docs resp. the
> filters docs, too...
Correct. But, we really only have two user-visible filters that
aren't experimental. -- justin
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> AddOutputFilterByType DEFLATE;INCLUDES text/html
>
> Err, yeah, the code doesn't like that. I'll try to fix that up
> today if I get a chance.
ok, I see the change, but two points:
- AFAICS the filter ordering is still reversed (in contrast to the
mod_mime definition)?
- this ordering doesn't affect the DEFLATE and INCLUDES filter
(because of different filter types), right?. If so, they are
bad examples for the "filter;filter" notation in general.
Perhaps this should be mentioned in the mod_mime docs resp. the
filters docs, too...
nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://www.perlig.de/> #
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> AddOutputFilterByType DEFLATE;INCLUDES text/html
>
> Err, yeah, the code doesn't like that. I'll try to fix that up
> today if I get a chance.
ok, I see the change, but two points:
- AFAICS the filter ordering is still reversed (in contrast to the
mod_mime definition)?
- this ordering doesn't affect the DEFLATE and INCLUDES filter
(because of different filter types), right?. If so, they are
bad examples for the "filter;filter" notation in general.
Perhaps this should be mentioned in the mod_mime docs resp. the
filters docs, too...
nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://www.perlig.de/> #
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 02:08:45AM +0200, André Malo wrote:
> +<p>If you want the content to be processed by more than one filter, you
> +have to use one <directive>AddOutputFilterByType</directive>
> +directive for each of them. Filters of the same type are processed in
> +<strong>reversed</strong> order they appear in your configuration,
> +but see also <a href="../sections.html#mergin">in which order
> +configuration sections are merged</a>.</p>
Hmm, we should be able to support DEFLATE;INCLUDES. For example:
AddOutputFilterByType DEFLATE;INCLUDES text/html
Err, yeah, the code doesn't like that. I'll try to fix that up
today if I get a chance.
Otherwise, +1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 02:08:45AM +0200, André Malo wrote:
> +<p>If you want the content to be processed by more than one filter, you
> +have to use one <directive>AddOutputFilterByType</directive>
> +directive for each of them. Filters of the same type are processed in
> +<strong>reversed</strong> order they appear in your configuration,
> +but see also <a href="../sections.html#mergin">in which order
> +configuration sections are merged</a>.</p>
Hmm, we should be able to support DEFLATE;INCLUDES. For example:
AddOutputFilterByType DEFLATE;INCLUDES text/html
Err, yeah, the code doesn't like that. I'll try to fix that up
today if I get a chance.
Otherwise, +1. -- justin