On Wed, Jun 11, 2014 at 07:06:13PM +0200, Marcus Rueckert wrote: > On 2014-06-11 17:59:27 +0200, Willy Tarreau wrote: > > On Wed, Jun 11, 2014 at 05:54:36PM +0200, Marcus Rueckert wrote: > > > On 2014-06-11 16:52:07 +0200, Willy Tarreau wrote: > > > > On Wed, Jun 11, 2014 at 08:54:31AM -0500, John Thompson wrote: > > > > > Thanks so much Willy, I can confirm that this patch resolves the > > > > > issue for me. > > > > > > > > Perfect, thanks for your feedback! > > > > > > Just tested myself. it seems if timeout client is smaller than timeout > > > http-keep-alive > > > then it seems to disconnect the client at the timeout client value. > > > > So that's the intended behaviour that we always had (we didn't play with the > > values there, just the fact that timeouts were artificially disabled on the > > client side to allow reporting the timeout issue at the proper moment). > > Is this described in the docs somewhere? I think even a small graph > which timeout kicks in when under which condition would be nice.
I'm realizing that it's not explicit. It's only implied by the fact that it serves purposes where people want "very short timeouts". In general, the client and server timeouts are the upper margin as they apply to the connection itself. The only exception being the tunnel timeout which was added for the purpose of supporting WebSocket and CONNECT requests without extra-large client/server timeouts. I don't have a clear idea how to represent this though :-/ Willy
