On 05/24/2011 07:41 PM, Justin Erenkrantz wrote:
> On Mon, May 23, 2011 at 8:08 PM, Ruediger Pluem <[email protected]> wrote:
>> Indeed this sounds like a general problem, but
>> ap_remove_output_filter does adjust r->output_filters if f->r is set and the
>> filter is the first one in the chain.
>> Which responses exactly suffer from this behaviour?
>
> Use "SetOutputFilter DEFLATE" and issue a GET request for a file w/o
> Accept-Encoding headers to Subversion (via mod_dav). You'll see that
> mod_deflate tries to remove itself, but mod_dav keeps invoking it.
> It's at the point where most companies who support Subversion refuse
> to support mod_deflate/gzip due to this issue.
Thanks. IMHO this is a design flaw in the DAV provider API in conjunction
with the current filter API:
dav_error * (*deliver)(const dav_resource *resource,
ap_filter_t *output);
deliver is usually called with r->output_filters as a second parameter and
thus makes a copy of the contents of r->output_filters and hence does not
notice if r->output_filters changes during the process of pushing content thru
the filter chain by multiple calls to ap_pass_brigade.
My idea would be to change the DAV API to either
dav_error * (*deliver)(const dav_resource *resource,
request_rec *r);
and using r->output_filters in the implementations of the deliver method in
the dav_providers or
dav_error * (*deliver)(const dav_resource *resource,
ap_filter_t **output);
and using *output in the implementations of the deliver method in
the dav_providers and calling deliver with &(r->output_filters) as second
parameter.
BTW: Same thing applies to deliver_report and merge.
Regards
Rüdiger
