*From: *Willy Tarreau <w...@1wt.eu> *Sent: * 2014-05-02 14:00:24 E *To: *Patrick Hemmer <hapr...@stormcloud9.net> *CC: *Rachel Chavez <rachel.chave...@gmail.com>, haproxy@formilux.org *Subject: *Re: please check
> On Fri, May 02, 2014 at 01:32:30PM -0400, Patrick Hemmer wrote: >> I've set up a test scenario, and the only time haproxy responds with 408 >> is if the client times out in the middle of request headers. If the >> client has sent all headers, but no body, or partial body, it times out >> after the configured 'timeout server' value, and responds with 504. > OK that's really useful. I'll try to reproduce that case. Could you please > test again with a shorter client timeout than server timeout, just to ensure > that it's not just a sequencing issue ? I have. In my test setup, "timeout client 1000" and "timeout server 2000". With incomplete headers I get: haproxy[8893]: 127.0.0.1:41438 [02/May/2014:14:11:26.373] f1 f1/<NOSRV> -1/-1/-1/-1/1001 408 212 - - cR-- 0/0/0/0/0 0/0 "<BADREQ>" With no body I get: haproxy[8893]: 127.0.0.1:41439 [02/May/2014:14:11:29.576] f1 b1/s1 0/0/0/-1/2002 504 194 - - sH-- 1/1/1/1/0 0/0 "GET / HTTP/1.1" With incomplete body I get: haproxy[8893]: 127.0.0.1:41441 [02/May/2014:14:11:29.779] f1 b1/s1 0/0/0/-1/2002 504 194 - - sH-- 0/0/0/0/0 0/0 "GET / HTTP/1.1" > >> Applying the patch solves this behavior. But my test scenario is very >> simple, and I'm not sure if it has any other consequences. > It definitely has, which is why I'm trying to find the *exact* problem in > order to fix it. > > Thanks, > Willy > > -Patrick
