httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/
Date Tue, 22 Mar 2016 17:11:33 GMT
In r1736216, I tried to restore c->data_in_input_filters usage as
prior to r1734656.
Does it help (or I'll revert)?

On Tue, Mar 22, 2016 at 1:02 PM, Jim Jagielski <> wrote:
> Well, we gotta do something. This is a significant breakage.
>> On Mar 15, 2016, at 4:29 AM, Yann Ylavic <> wrote:
>> On Tue, Mar 15, 2016 at 12:42 AM, Graham Leggett <> wrote:
>>> On 14 Mar 2016, at 10:48 AM, Ruediger Pluem <> wrote:
>>>> This seems to cause frequent (no always) failures with test 8 of t/ssl/proxy.t.
>>>> The request times out with a 504 status. So it looks like the "backend" in
this request does not respond.
>>>> Used MPM is Event, OS CentOS 6 64 Bit. Without further investigating my closeset
guess would be that the changes to
>>>> checkpipeline cause this.
>>> I commented out check_pipeline() completely, and it passed all the tests.
>>> Looking at check_pipeline, it seems to try and eat trailing CRLFs, which is duplicating
the functionality in read_request_line() which eats preceding CRLFs already.
>>> check_pipeline() seems to have been overhauled recently, not sure what problem
it is trying to solve. Can we remove it?
>> No we can't, or at least we need to eat the trailing CRLFs.
>> Otherwise they will be considered as a pipelined request, thus if no
>> request is really following, we will block in read_request_line(), w/o
>> FLUSHing the previous response.
>> For mpm event, that also causes a spurious wake up (defeating
>> non-blocking since read_request_line() is/was? blocking).
>> But maybe your recent changes could avoid this, dunno, at least we
>> need to flush when there is no real pipelined request already there
>> (after the CRLFs).
>> Regards,
>> Yann.

View raw message