On Fri, Sep 22, 2017 at 11:39:54AM -0500, William A Rowe Jr wrote: > This defect still appears to exist in 2.4.28-dev, no? > > The rewrite appears to have enjoyed both committer and external testing and > the patch looks suitable for backport. It has enjoyed careful consideration by > at least four committers. > > Reading https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c19 Joe was > eyeing some additional improvements, but it seems worthwhile to get this > defect fixed in today's T&R. > > Joe, is there a reason to hold on backporting, why this hasn't been promoted > to 2.4 STATUS? If you are satisfied, here's my +1 for the backport to speed > things up.
I don't plan any additional changes, no. But I'm not very confident we should be throwing a major rewrite of a core filter at 2.4 users with only light testing, especially since there are security fixes pending. I have put this patch in Fedora "Raw Hide" builds to give some extra exposure, and I'd love to hear more testing results here. Given that the bug has sat festering for a long time (maybe since 2.2??) I don't see any urgency, I'd rather get a bit more testing and wait until after .28 to ship and avoid regressions. Regards, Joe > On Wed, Sep 13, 2017 at 5:59 AM, <jor...@apache.org> wrote: > > Author: jorton > > Date: Wed Sep 13 10:59:51 2017 > > New Revision: 1808230 > > > > URL: http://svn.apache.org/viewvc?rev=1808230&view=rev > > Log: > > * server/protocol.c (ap_content_length_filter): Rewrite the content > > length filter to avoid arbitrary memory consumption for streaming > > responses (e.g. large CGI script output). Ensures C-L is still > > generated in common cases (static content, small CGI script output), > > but this DOES change behaviour and some responses will end up > > chunked rather than C-L computed. > > > > PR: 61222 > > Submitted by: jorton, rpluem
