Done!
Thanks a lot Willy,
On Thu, Nov 12, 2015 at 8:26 PM Willy Tarreau wrote:
> Hi Laurent,
>
> On Thu, Nov 12, 2015 at 06:44:42PM +, Laurent Senta wrote:
> > >
> > >
> > > > I traced back that change to:
> > > >
> > >
> http://git.haproxy.org/?p=haproxy-1.6.git;a=commit;h=6b726adb35d998eb
Hi Laurent,
On Thu, Nov 12, 2015 at 06:44:42PM +, 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 hi
>
>
> > 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
> >
On Wed, Nov 11, 2015 at 06:55:11PM -0800, Bryan Talbot wrote:
> On Wed, Nov 11, 2015 at 6:47 AM, Holger Just wrote:
>
> >
> > As a loadbalancer however, HAProxy should always return a proper HTTP
> > error if the request was even partially forwarded to the server. It's
> > probably fine to just c
On Wed, Nov 11, 2015 at 6:47 AM, Holger Just wrote:
>
> As a loadbalancer however, HAProxy should always return a proper HTTP
> error if the request was even partially forwarded to the server. It's
> probably fine to just close the connection if the connect timeout stroke
> and the request was ne
Hi,
Willy Tarreau wrote:
> 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 t
Hi,
On Wed, Nov 11, 2015 at 03:46:38AM +, Laurent Senta wrote:
> Thanks for the reply guys,
> after investigating the source code, it looks like this behavior is wanted.
Yes, it is mandated by the way keep-alive works in HTTP. You never know when
the connection will abort, and at the moment y
Thanks for the reply guys,
after investigating the source code, it looks like this behavior is wanted.
I've been able to "fix it" by removing these two lines:
diff --git a/src/proto_http.c b/src/proto_http.c
index 2dcac06..d33b4a1 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6125,8 +6
On Tue, Nov 10, 2015 at 7:32 PM, Bryan Talbot wrote:
> On Tue, Nov 10, 2015 at 12:04 PM, Laurent Senta
> wrote:
>>
>> Hi there,
>> I think there's a bug in how HAProxy handles timeout, that'd be great if
>> you can confirm or help me figure out what I do wrong:
>>
>> Basically: if a server timeou
On Tue, Nov 10, 2015 at 12:04 PM, Laurent Senta
wrote:
> Hi there,
> I think there's a bug in how HAProxy handles timeout, that'd be great if
> you can confirm or help me figure out what I do wrong:
>
> Basically: if a server timeout happens on a keep-alive connection, haproxy
> does not write a
Hi there,
I think there's a bug in how HAProxy handles timeout, that'd be great if
you can confirm or help me figure out what I do wrong:
Basically: if a server timeout happens on a keep-alive connection, haproxy
does not write a 504 response before closing the socket.
This leads python to fail w
11 matches
Mail list logo