Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> writes:
> It might be possible to rework mod_dav_svn, although it's going to take
> some time. Currently, every top-level handler receives an `ap_filter_t *`
> and passes it further, and all these places would have to be updated so
> that the actual writes would target r->output_filters.
> There also is the function in the core part of mod_dav that shares the same
> kind of problem and requires a separate fix. Please see mod_dav.h:554:
> DAV_DECLARE(void) dav_send_one_response(dav_response *response,
> apr_bucket_brigade *bb,
> ap_filter_t *output,
> apr_pool_t *pool);
> For a start, I prepared two patches for mod_dav:
> - The first patch fixes the problem in dav_send_one_response(). Please note
> that while dav_send_one_response() is public API, it's not yet released as
> of 2.4.23. So, this patch changes it directly, without introducing a new
> dav_send_one_response2() function for compatibility.
> - The second patch notes the API issue in the docs for the mentioned DAV
> hooks, deliver(), deliver_report() and merge() — for the sake of anyone
> who might be implementing a DAV provider.
> The patches are attached (log messages are in the beginning of each file).
For the record, I completed a rework of mod_dav_svn that fixes a part
of the issue. Now, all writes within mod_dav_svn target the actual filter
list in r->output_filters, and this fixes one cause of the unbounded memory
However, the second cause of the unbounded memory usage is still present
in mod_dav. This part of the issue is addressed by my patches from the
Does someone have the time and energy to review these two patches? Or
maybe there's something in these patches that requires improving?
Just in case, the patches are also available here:
Thanks in advance!
Received on 2016-08-29 18:12:32 CEST