On 05/27/2011 09:50 AM, Greg Stein wrote:
> On Wed, May 25, 2011 at 02:53, 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.
>
> 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.
Hence my second idea of
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.
>
> 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?
We don't and you are correct that this only solves the mod_dav issue.
So your idea would be to change the filter API in a way that r->output_filters
remains constant between ap_pass_brigade calls?
The easiest, but maybe ugly, idea that comes to my mind here is to add a dummy
filter as the very first filter that only passes the brigade and never gets
removed
during ap_pass_brigade calls.
Regards
Rüdiger
