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 <j...@jagunet.com> wrote: > Well, we gotta do something. This is a significant breakage. > >> On Mar 15, 2016, at 4:29 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> 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. >
