On Wed, May 25, 2011 at 02:53, Ruediger Pluem <[email protected]> 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.
Yup... > 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 I chose not to do it this way because I wanted to isolate the DAV providers as much as possible from the request_rec. The idea was to keep them relatively independent of the fact that the provider is operating within an HTTP server. Passing r->output_filter was a much "narrower" view than passing the entire request_rec. The request_rec has got a LOT of exposure to the innards of the server, and I didn't want providers to worry about that, and certainly not to muck around with it and do funny things. Obviously, that approach has now caused a problem where you have filter that want to remove themselves. I would posit that even if you solve the mod_dav case, that the problem would *still* exist. Other content generators might grab r->output_filters at the beginning of their operation, and then never notice a change in the request_rec. mod_dav does this, but how do we know that others do not? Cheers, -g
