On Tue, Mar 15, 2016 at 12:42 AM, Graham Leggett <minf...@sharp.fm> wrote: > On 14 Mar 2016, at 10:48 AM, Ruediger Pluem <rpl...@apache.org> 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.
