------------------------------------------------------------------------ *From: *Lukas Tribus <luky...@hotmail.com> *Sent: * 2014-06-24 06:44:44 EDT *To: *Willy Tarreau <w...@1wt.eu>, Patrick Hemmer <hapr...@stormcloud9.net> *CC: *haproxy@formilux.org <haproxy@formilux.org>, Rachel Chavez <rachel.chave...@gmail.com> *Subject: *RE: 3rd regression : enough is enough!
> > ---------------------------------------- >> Date: Tue, 24 Jun 2014 07:33:41 +0200 >> From: w...@1wt.eu >> To: hapr...@stormcloud9.net >> CC: haproxy@formilux.org; rachel.chave...@gmail.com >> Subject: Re: 3rd regression : enough is enough! >> >> Hi Patrick, >> >> On Mon, Jun 23, 2014 at 09:30:11PM -0400, Patrick Hemmer wrote: >>> This is unfortunate. I'm guessing a lot of the issue was in ensuring the >>> client timeout was observed. Would it at least be possible to change the >>> response, so that even if the server timeout is what kills the request, >>> that the client gets sent back a 408 instead of a 503? >> For now I have no idea. All the mess came from the awful changes that >> were needed to ignore the server-side timeout and pretend it came from >> the client despite the server triggering first. This required to mess >> up with these events in a very dangerous way :-( >> >> So right now I'd suggest to try with a shorter client timeout than the >> server timeout. I can try to see how to better *report* this specific >> event if needed, but I don't want to put the brown paper bag on >> timeouts anymore. > I fully agree. > > > But perhaps we can document the current behavior in those particular > conditions better, so that this is better known until we find a good > code-based solution. > > > What is the issue here exactly? When the client uploads large POST > requests and the server timeout is larger than the client timeout, > we will see a sD flag in the log? Is that all, or are there other > conditions in which a client timeout trigger a sD log? The issue is that the 'timeout client' parameter isn't being observed once the client goes into the data phase. If the server is waiting for data (http body), it won't send anything back until the client sends in a body. Since 'timeout client' isn't being observed, the 'timeout server' kicks in and haproxy responds with a 503 because the server took too long to respond when it was really the client's issue because the client didn't send a body. This is supposed to be a 408. > Can it be workarounded completely by configuring the server timeout > larger then the client timeout? > > > > > > Regards, > > Lukas > >
