Re: Lingering Close

Mark Nottingham <mnot@mnot.net> Sun, 20 January 2013 03:09 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304F521F850C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Jan 2013 19:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.217
X-Spam-Level:
X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[AWL=1.382, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16cqx01FjE-P for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Jan 2013 19:09:18 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 37A9621F84FC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 19 Jan 2013 19:09:18 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TwlGV-0005d1-Qk for ietf-http-wg-dist@listhub.w3.org; Sun, 20 Jan 2013 03:08:11 +0000
Resent-Date: Sun, 20 Jan 2013 03:08:11 +0000
Resent-Message-Id: <E1TwlGV-0005d1-Qk@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1TwlGS-0005cM-9a for ietf-http-wg@listhub.w3.org; Sun, 20 Jan 2013 03:08:08 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1TwlGR-0002XN-Hg for ietf-http-wg@w3.org; Sun, 20 Jan 2013 03:08:08 +0000
Received: from [192.168.1.80] (unknown [118.209.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EAB7422E1FA; Sat, 19 Jan 2013 22:07:44 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CACuKZqHimG7aki_OLBHQ--Bh83Wf=Ak3o6VC1XYWWCGf57fQEw@mail.gmail.com>
Date: Sun, 20 Jan 2013 14:07:41 +1100
Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ED40DF1-DE29-44B4-8241-0E32B7244E42@mnot.net>
References: <CACuKZqGcDvFu_r=DWKPv2AkhcbDgoB6jOam3GMLJoz9HFEFSEg@mail.gmail.com> <20121128174449.GD7227@1wt.eu> <CACuKZqHyhhKRmZ-LyW7RWb-YSCW_Nq1+XLdwA8H9=eugt0UQYw@mail.gmail.com> <20121128190805.GG7227@1wt.eu> <CACuKZqEDnuWsMTrBtEFi9es76hNa=SAaD+5nUQxRnO_jVM8EUw@mail.gmail.com> <20121128202240.GH7227@1wt.eu> <CACuKZqHcBFP-4qv4N8TEyXQEttg1rfZzZ7K+ob8jHAV_4czcLg@mail.gmail.com> <20121129002943.GA11277@1wt.eu> <CACuKZqHimG7aki_OLBHQ--Bh83Wf=Ak3o6VC1XYWWCGf57fQEw@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.187, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1TwlGR-0002XN-Hg b24c22c30b2148f3384fc10fcb636623
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Lingering Close
Archived-At: <http://www.w3.org/mid/2ED40DF1-DE29-44B4-8241-0E32B7244E42@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16036
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Closing the loop on this thread -

* AFAICT the current text is adequate (if not perfect). If someone disagrees, please propose text ASAP.

* There was some discussion of improving the mapping of HTTP to TCP. If folks have ideas, we can certainly write requirements documents, etc. Remember that our charter has been broadened somewhat WRT HTTP extensions, etc.

* We *can* discuss how HTTP/2 uses TCP in this WG.

Cheers,


On 29/11/2012, at 1:11 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> On Wed, Nov 28, 2012 at 6:29 PM, Willy Tarreau <w@1wt.eu> wrote:
>> 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
> 
> "lingering close" is also mentioned in previous texts. give it a new
> distinct name?
> 
>> Willy
>> 
> 

--
Mark Nottingham   http://www.mnot.net/