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 ?


Reply via email to