Re: p2: Expect: 100-continue and "final" status codes

Willy Tarreau <w@1wt.eu> Wed, 24 April 2013 06:24 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 8155321F8EC1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 23:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.209
X-Spam-Level:
X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Ibgdcjgg6WbJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 23:24:03 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0323C21F8D13 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 23:24:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUt7E-0008SU-2E for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 06:23:40 +0000
Resent-Date: Wed, 24 Apr 2013 06:23:40 +0000
Resent-Message-Id: <E1UUt7E-0008SU-2E@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUt7A-0008RH-Gg for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 06:23:36 +0000
Received: from 1wt.eu ([62.212.114.60]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUt6q-0000Sa-BD for ietf-http-wg@w3.org; Wed, 24 Apr 2013 06:23:22 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3O6LXJo018714; Wed, 24 Apr 2013 08:21:33 +0200
Date: Wed, 24 Apr 2013 08:21:33 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20130424062133.GE15918@1wt.eu>
References: <750CBB7A-3E82-4D2A-871E-159E9F030E6F@mnot.net> <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com> <5B49FDCD-93D3-4DD8-BF05-DFB30511343E@mnot.net> <51774650.50104@treenet.co.nz> <4805210C-9117-4E5E-9D95-9E9A12A0CE03@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4805210C-9117-4E5E-9D95-9E9A12A0CE03@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.092, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUt6q-0000Sa-BD 11a5913b98586ddc3d577dd6a69cf22b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p2: Expect: 100-continue and "final" status codes
Archived-At: <http://www.w3.org/mid/20130424062133.GE15918@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17524
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>

On Wed, Apr 24, 2013 at 01:32:16PM +1000, Mark Nottingham wrote:
> 
> On 24/04/2013, at 12:41 PM, Amos Jeffries <squid3@treenet.co.nz>; wrote:
> >>> 
> >>> I think we can give better advice than that. If a server responds with a final status code instead of 100 (Continue)
> >>> 
> >>> 1. The response must be the last response on the connection. The response should contain "Connection: close" header. After the response is written, the server must initiate a lingering close of the connection (p1#6.6).
> >> That seems too restrictive; as long as the server reads the rest of the request properly (discarding it), it should be able to recover and reuse the connection.
> > 
> > The problem comes with intermediaries. How are they to know the bytes following were the original advertised payload or not? the status from server has no guarantee of arriving after the client payload starts arriving.
> > The only way to guarantee safety on the connection is to close it or always send payload.
> 
> 
> True. 

+1 as well

Willy