Done! Thanks a lot Willy,
On Thu, Nov 12, 2015 at 8:26 PM Willy Tarreau <[email protected]> wrote: > Hi Laurent, > > On Thu, Nov 12, 2015 at 06:44:42PM +0000, Laurent Senta wrote: > > > > > > > > > > I traced back that change to: > > > > > > > > http://git.haproxy.org/?p=haproxy-1.6.git;a=commit;h=6b726adb35d998eb55671c0d98ef889cb9fd64ab > > > > > > > > I don't understand why it's saner to kill the connection and hide > the 504 > > > > instead of clearly stating the error and let the application handle > the > > > > timeout. > > > > > > As explained above, it's because a keep-alive enabled client must > implement > > > the ability to replay requests for which it didn't get a response > because > > > the connection died. In fact we're forwarding to the client what we > saw on > > > the server side so that the client can take the correct decision. If > your > > > client was directly connected to the server, it would have seen the > exact > > > same behaviour. > > > > > > > That's where it gets confusing. HAProxy treats a server timeout on the > > first request and the nth request differently and I don't see why. > > > > There are no semantic differences between a timeout on the first or on > the > > second request of the keep-alive connection. If I see a 504 when it's the > > first request, why don't I see a 504 when it's the second? > > That's what I said in the thread before the paragraph you quoted above, I > do > think that the 504 should always be sent because I don't see how it could > be related to a keep-alive connection failure, except in environments > where keep-alive timeout is configured longer than firewall timeouts, but > even then you'd prefer to log it so that it can be fixed. > > However all other cases (aborted connections with no data) must remain > silent by default. > > I'm willing to change this and even to backport the change into 1.5 as I > admit it doesn't provide value and only hides real trouble. I asked if > people were OK with my proposal but instead I got comments about why we > are doing it like this right now :-/ > > > It's not related to RFCs, I know they say almost nothing on keep-alive > > connection getting closed. > > The retry rules are explained in 6.3.1 of RFC7230. There's not much about > this but it's mostly based on common sense once you have ingurgited all > the stuff around this section so there's not much more than needs be said. > > > I'm not advocating having this as the default behavior (even though I > think > > the current default is wrong and it should be documented), but at least > > having this as an option, or include it in http-server-close if it even > > makes sense. > > For the 504 I'm definitely willing to fix the default behaviour. For the > other ones, we definitely cannot change it without an option. And I really > guess this option will only result in misuses or will never be used. So > let's do it for 504 only. > > Do you want to submit a patch for this with a detailed enough description > so that if someone suffers from the behaviour change we have all the > context ? > > Thanks, > Willy > >
