On Tue, May 24, 2011 at 8:53 PM, Ruediger Pluem <rpl...@apache.org> wrote: > On 05/24/2011 07:41 PM, Justin Erenkrantz wrote: >> On Mon, May 23, 2011 at 8:08 PM, Ruediger Pluem <rpl...@apache.org> 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.
Sure - changing APIs like this is one way to solve it; but that's not a legitimate option for 2.2.x. When this was discussed on dev@subversion, I know Greg was reluctant to see the mod_dav APIs revved after so long. =) -- justin
