On Fri, May 02, 2014 at 02:14:41PM -0400, Patrick Hemmer wrote: > *From: *Willy Tarreau <[email protected]> > *Sent: * 2014-05-02 14:00:24 E > *To: *Patrick Hemmer <[email protected]> > *CC: *Rachel Chavez <[email protected]>, [email protected] > *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"
Great, thank you. I think that it tends to fuel the theory that the response error is not set where it should be in the forwarding path. I'll check this ASAP. BTW, it would be nice if you could check this as well with 1.4.25, I guess it does the same. Best regards, Willy
