Done!

Thanks a lot Willy,

On Thu, Nov 12, 2015 at 8:26 PM Willy Tarreau <w...@1wt.eu> 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
>
>

Reply via email to