https://bz.apache.org/bugzilla/show_bug.cgi?id=58856
Bug ID: 58856
Summary: AddOutputFilterByType in Apache 2.4 inserts filters as
AP_FTYPE_RESOURCE
Product: Apache httpd-2
Version: 2.4.18
Hardware: All
OS: All
Status: NEW
Keywords: PatchAvailable
Severity: regression
Priority: P2
Component: mod_filter
Assignee: [email protected]
Reporter: [email protected]
Created attachment 33441
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33441&action=edit
Fix regression of AddOutputFilterByType using wrong filter type
As reported also per mail:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201601.mbox/%3C64eebd8fd16ad6b8a4a187b5d349f169%40mail.lenk.info%3E
PROBLEM DESCRIPTION
I observed that the behavior of this directive changed in Apache 2.4 for
filters. Starting with Apache 2.4 filters are inserted at an earlier
place in the filter chain than they were inserted with Apache 2.2. For
example, if you use the directive
AddOutputFilterByType DEFLATE text/html
The filter is inserted with AP_FTYPE_RESOURCE, even though it was
registered in mod_deflate.c as AP_FTYPE_SET_CONTENT.
The effect is that using "AddOutputFilterByType DEFLATE text/html" the
resulting filter chain is ordered diferrently compared to using
"SetOutputFilter DEFLATE".
This can be fixed in configuration by adding the following directive
right after AddOutputFilterByType:
FilterDeclare BYTYPE:DEFLATE CONTENT_SET
Unfortunately the order and placement of FilterDeclare seems to be
relevant, i.e. this fix only works if FilterDeclare comes *after*
AddOutputFilterByType within the same container.
I wonder whether this is an intentional behavior change of
AddOutputFilterByType or not.
ANALYSIS
Apparently the filter type (ap_filter_rec_t struct member ftype) of the
filter provider isn't respected anymore.
The intended filter type is provided when registering the output filter
by calling ap_register_output_filter(). In branch 2.2.x this was
sufficient, because the conditional filter (based on the MIME type) was
added directly by name (i.e. by calling ap_add_output_filter() in
ap_add_output_filters_by_type). In branches 2.4.x and trunk the
implementation of AddOutputFilterByType apparently moved to mod_filter
and a layer of indirection (the filter harness) is introduced. But the
filter harness is apparently created unconditionally with
AP_FTYPE_RESOURCE.
FIX APPROACH
When implicitly creating a filter harness by calling the function
add_filter(), we have access to the provider's ap_filter_rec_t anyways.
So I recommend to just copy it from the filter provider (e.g. DEFLATE)
to the filter harness (e.g. BYTYPE:DEFLATE).
I've tested this approach with the attached patch for a setup without any
FilterDeclare directive, and it fixed the regression; the DEFLATE filter
was ordered correctly at AP_FTYPE_CONTENT_SET again.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
