httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: svn commit: r1103315 - /httpd/httpd/trunk/modules/filters/mod_deflate.c
Date Fri, 27 May 2011 07:50:56 GMT
On Wed, May 25, 2011 at 02:53, Ruediger Pluem <> 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

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?


View raw message