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
