W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: Lingering Close

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 29 Nov 2012 01:29:43 +0100
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20121129002943.GA11277@1wt.eu>
On Wed, Nov 28, 2012 at 03:13:03PM -0600, Zhong Yu wrote:
> On Wed, Nov 28, 2012 at 2:22 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Wed, Nov 28, 2012 at 01:24:15PM -0600, Zhong Yu wrote:
> >> Thanks Willy, I think I get what you mean by now. FIN should be
> >> initiated by server to avoid the TIME_WAIT problem. Therefore the
> >> half-close step is important.
> >
> > exactly.
> >
> >> The current text makes perfect sense to me now.
> >
> > With this in mind, do you think that something in the text should be
> > updated for future readers ?
> 
> The text gives motivation for draining (to avoid RST), it probably
> should give motivation for half-close as well. The text may become too
> long and out of scope, but I agree with Jamie Lokier that it's better
> to warn implementers about the issues.

I too was caught in the past by this and have had to perform several
incremental changes on haproxy to address this, including for responses
caught from some servers.

> Also, I would probably use a different word than "linger"; at first
> read I though it means kernel's lingering.

It was my case too when reading this sentence out of context.

Maybe a small change like this would be appropriate ?


-   To avoid the TCP reset problem, a server can perform a lingering
-   close on a connection by closing only the write side of the read/
-   write connection (a half-close) and continuing to read from the
-   connection until the connection is closed by the client or the server

+   To avoid the TCP reset problem, a server can shut down the write side
+   of the connection (also called a half-close) and continuing to read from
+   the connection until the connection is closed by the client or the server

Willy
Received on Thursday, 29 November 2012 00:30:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 November 2012 00:30:14 GMT