Re: WGLC p1: Tear-down

Mark Nottingham <mnot@mnot.net> Tue, 30 April 2013 02:50 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 82DB721F9C27 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 19:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.024
X-Spam-Level:
X-Spam-Status: No, score=-10.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JZfwUjV5FMN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 19:50:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 520CE21F9BF3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 19:50:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UX0dp-00084M-TT for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Apr 2013 02:50:05 +0000
Resent-Date: Tue, 30 Apr 2013 02:50:05 +0000
Resent-Message-Id: <E1UX0dp-00084M-TT@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UX0dg-0006n3-U6 for ietf-http-wg@listhub.w3.org; Tue, 30 Apr 2013 02:49:56 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UX0dg-0003Gm-90 for ietf-http-wg@w3.org; Tue, 30 Apr 2013 02:49:56 +0000
Received: from mnot-mini.mnot.net (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C97050A84; Mon, 29 Apr 2013 22:49:34 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <ECD24B2A-B90F-4A68-B405-8DE029D6A232@niven-jenkins.co.uk>
Date: Tue, 30 Apr 2013 12:49:31 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EEE9043-AAB0-4C37-9E3A-6AB17068E4AD@mnot.net>
References: <ECD24B2A-B90F-4A68-B405-8DE029D6A232@niven-jenkins.co.uk>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.389, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UX0dg-0003Gm-90 197f8ee2b3b2c6173034ff53e798bd49
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC p1: Tear-down
Archived-At: <http://www.w3.org/mid/5EEE9043-AAB0-4C37-9E3A-6AB17068E4AD@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17705
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>

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/477> (editorial).

Thanks,


On 30/04/2013, at 5:33 AM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:

> Section 6.6 of p1 states:
> 
>   A server that sends a close connection option MUST initiate a
>   lingering close of the connection after it sends the response
>   containing close.  The server MUST NOT process any further requests
>   received on that connection.
> 
>   A client that receives a close connection option MUST cease sending
>   requests on that connection and close the connection after reading
>   the response message containing the close; if additional pipelined
>   requests had been sent on the connection, the client SHOULD assume
>   that they will not be processed by the server.
> 
> The last sentence can be interpreted one of two ways:
> 1) The client SHOULD assume the additional pipelined requests will NOT be processed by the server and therefore can happily re-try them knowing the server has not processed the previous ones.
> 
> 2) The client SHOULD NOT assume the additional pipelined requests will be processed (which implies the client simply can not know whether the server has processed them or not).
> 
> As the client has no way of knowing whether the server may have processed them or not (e.g. the client may be talking to a proxy that has already relayed the pipelined requests to the origin and done so before the proxy was aware that it wanted to close the connection on this response) I would suggest rewording the last sentence quoted above:
> 
> OLD:
>   the client SHOULD assume that they will not be processed by the server.
> NEW:
>   the client SHOULD NOT assume that they will be processed by the server.
> 
> 
> Thanks
> Ben
> 
> 

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