On 05/27/2011 06:11 AM, Justin Erenkrantz wrote: > On Tue, May 24, 2011 at 8:53 PM, Ruediger Pluem <rpl...@apache.org> wrote:
>> 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 That's the beauty of your solution: It can be backported to 2.2.x. But it only solves the issue for mod_deflate and not for other filters. But in the light of an upcoming 2.4.x which makes these kind of API changes impossible again for a long time I wanted to start a discussion about how to fix this in a general way for all filters. > dev@subversion, I know Greg was reluctant to see the mod_dav APIs > revved after so long. =) -- justin I am open for other proposals, e.g. to fix the filter API, but I haven't found an approach that I like yet. Regards Rüdiger
