Re: AddOutputFilterByType in Apache 2.4 inserts filters as AP_FTYPE_RESOURCE

[Nick Kew <ni...@apache.org>]

On Wed, 2016-01-13 at 17:59 +0100, Micha Lenk wrote:
> Hi,
> 
> The directive AddOutputFilterByType can be used to insert filters to the 
> output filter chain depending on the content type of the HTTP response. 
> So far so good.
> 
> PROBLEM DESCRIPTION

This is probably worth a bugzilla entry.

I think I can clarify a little of what's happened.
AddOutputFilterByType was something of a hacked afterthought
to filtering back in the days of httpd 2.0.  On the one hand,
it met a need.  On the other hand, it worked only in a very
limited range of situations where the content type was known
at the time the filter was to be added.  It had no capacity
to respond to other aspects of the content, or indeed the
request/response.  And there were other issues.

Then came mod_filter and a generalised framework.
AddOutputFilterByType was now obsolete, but too widely-used
to dispense with entirely.  As a compromise it was re-implemented
within mod_filter, where it could co-exist with other dynamic
filter configuration.

Your observation tells us the semantics aren't quite compatible.
And your patch looks good - thanks.

-- 
Nick Kew

Re: AddOutputFilterByType in Apache 2.4 inserts filters asAP_FTYPE_RESOURCE

[Micha Lenk <mi...@lenk.info>]

Hi Nick,

if the patch looks good, as you wrote, what is needed to get it applied 
to trunk and backported to 2.4.x?

Have you seen my follow-up questions in the other mail?

Best regards,
Micha


Am 13.01.2016 22:44, schrieb Nick Kew:
> On Wed, 2016-01-13 at 17:59 +0100, Micha Lenk wrote:
>> Hi,
>> 
>> The directive AddOutputFilterByType can be used to insert filters to 
>> the
>> output filter chain depending on the content type of the HTTP 
>> response.
>> So far so good.
>> 
>> PROBLEM DESCRIPTION
> 
> This is probably worth a bugzilla entry.
> 
> I think I can clarify a little of what's happened.
> AddOutputFilterByType was something of a hacked afterthought
> to filtering back in the days of httpd 2.0.  On the one hand,
> it met a need.  On the other hand, it worked only in a very
> limited range of situations where the content type was known
> at the time the filter was to be added.  It had no capacity
> to respond to other aspects of the content, or indeed the
> request/response.  And there were other issues.
> 
> Then came mod_filter and a generalised framework.
> AddOutputFilterByType was now obsolete, but too widely-used
> to dispense with entirely.  As a compromise it was re-implemented
> within mod_filter, where it could co-exist with other dynamic
> filter configuration.
> 
> Your observation tells us the semantics aren't quite compatible.
> And your patch looks good - thanks.

Re: AddOutputFilterByType in Apache 2.4 inserts filters asAP_FTYPE_RESOURCE

[Micha Lenk <mi...@lenk.info>]

Hi Nick,

Am 13.01.2016 22:44, schrieb Nick Kew:
>> PROBLEM DESCRIPTION
> 
> This is probably worth a bugzilla entry.

Done. https://bz.apache.org/bugzilla/show_bug.cgi?id=58856

Nick, would you mind to provide some insights on these comments from my 
initial mail:
>> For setups with both, FilterDeclare and AddOutputFilterByType (as
>> described above as fix), I observed some issues with properly merging
>> the two filter harnesses. However, I have no clue what semantics the
>> original author wanted to have in this situation.

Assumed that my patch gets applied, the filter type should be correctly 
set in the filter harness. But what if a user wants to override it? I 
got a few questions in this context:

1.) Should "FilterDeclare" with filter-name "BYTYPE:DEFLATE" (i.e. 
colliding
     with the implicit filter-name created by AddOutputFilterByName) be
     supported at all?

1a.) If yes, the handling of AddOutputFilterByType needs to be fixed so 
that:
      - a globally configured FilterDeclare is also effective for an
        AddOutputFilterByType within a (location) sub-container.
      - a filter type set by "FilterDeclare BYTYPE:<provider> <filter 
type>"
        does not get overwritten by a subsequent
        "AddOutputFilterByType <provider>".

1b.) If no, the code should detect and reject such configurations.

2.) On a related note to 1., Should FilterDeclare allow a filter-name of
     existing filter providers at all? If yes, behavior would we expect?

Nick, I would be really glad if you could share your thoughts.

Best regards,
Micha