IETF Logo Mail Archive

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

Mark Nottingham <mnot@mnot.net> Wed, 24 April 2013 03:33 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 1FEE821F93BC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 20:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.466
X-Spam-Level:
X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JI-Vj2H+OMEC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 20:33:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22221F93B9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 20:33:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUqRp-0000qa-B6 for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 03:32:45 +0000
Resent-Date: Wed, 24 Apr 2013 03:32:45 +0000
Resent-Message-Id: <E1UUqRp-0000qa-B6@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 1UUqRl-0000pm-5b for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 03:32:41 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUqRk-000836-DK for ietf-http-wg@w3.org; Wed, 24 Apr 2013 03:32:41 +0000
Received: from [192.168.1.80] (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 B973A509B6; Tue, 23 Apr 2013 23:32:18 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51774650.50104@treenet.co.nz>
Date: Wed, 24 Apr 2013 13:32:16 +1000
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4805210C-9117-4E5E-9D95-9E9A12A0CE03@mnot.net>
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>
To: Amos Jeffries <squid3@treenet.co.nz>
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.349, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUqRk-000836-DK 00525d3300554bfe507197aef55b5150
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/4805210C-9117-4E5E-9D95-9E9A12A0CE03@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17518
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 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. 

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

v2.23.0 | Report a Bug | By Email