Well, we gotta do something. This is a significant breakage.
> On Mar 15, 2016, at 4:29 AM, Yann Ylavic <[email protected]> wrote:
>
> On Tue, Mar 15, 2016 at 12:42 AM, Graham Leggett <[email protected]> wrote:
>> On 14 Mar 2016, at 10:48 AM, Ruediger Pluem <[email protected]> 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.
