Re: #467: Expect: 100-continue and "final" status codes
Zhong Yu <zhong.j.yu@gmail.com> Tue, 28 May 2013 16:00 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 4BEFF21F97D1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 09:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7EOyTF7lpOV3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 08:59:59 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A900C21F976F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 08:59:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhMIH-0003jU-O8 for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 15:58:37 +0000
Resent-Date: Tue, 28 May 2013 15:58:37 +0000
Resent-Message-Id: <E1UhMIH-0003jU-O8@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UhMI2-0003iJ-KJ for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 15:58:22 +0000
Received: from mail-oa0-f45.google.com ([209.85.219.45]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UhMHs-00068h-Ud for ietf-http-wg@w3.org; Tue, 28 May 2013 15:58:22 +0000
Received: by mail-oa0-f45.google.com with SMTP id j6so10043065oag.4 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 08:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0QZmtt6Evdz7T3yp1AwZXtOXHQJivnX51nX97jZo9y8=; b=eCEfv5bz2y9PKN1KDg6az4D6ElfovVjBKHVuaByYgmuIJs/0kGJUJ3+c071c4sw5BZ EgUC2+Ytdh6zC+8saGA28ulHcjY1iHCquQPX52gBHrnfrfnkiZjw1CbF957KyX9UQ5bf 0lmnV6Kit8ioyETa5coDeCAE+7CIYenxLpjHRI/ZQpjM4JMmzmhUSrWlTu/41c5z8cre 1oIIHfz/0WPAhiGGCobGhYOQtEPXhMREO3VNzZATMMjBJjQWVhJnwTCMkPUzQsg29zJL qrbIeS+nBDyGpftHVgfTy1WhUNmhU0pd2DLiyRG68yaY7DZlx9mUA+7mYqbJWoeDvnA3 aXdA==
MIME-Version: 1.0
X-Received: by 10.60.79.198 with SMTP id l6mr20724238oex.47.1369756667059; Tue, 28 May 2013 08:57:47 -0700 (PDT)
Received: by 10.76.79.8 with HTTP; Tue, 28 May 2013 08:57:46 -0700 (PDT)
In-Reply-To: <9C460363-84A8-459E-A9F1-B6A1219F31D7@mnot.net>
References: <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com> <51780FBA.3080706@andrew.cmu.edu> <20130424170638.GD19750@1wt.eu> <1CD0C86A-CFBF-4DF6-A688-9E4EF549190E@mnot.net> <CACuKZqGwm+aH+jRSNmKsfdDwe3eCVhmtr=u0rbUFC2+G99T5VQ@mail.gmail.com> <9C460363-84A8-459E-A9F1-B6A1219F31D7@mnot.net>
Date: Tue, 28 May 2013 10:57:46 -0500
Message-ID: <CACuKZqEfKFhCyDqeq_HpMfoG==jcx7xGifd=+qbUqErTZvBLjQ@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, Ken Murchison <murch@andrew.cmu.edu>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e0118289e91ab2304ddc9530d"
Received-SPF: pass client-ip=209.85.219.45; envelope-from=zhong.j.yu@gmail.com; helo=mail-oa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.661, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UhMHs-00068h-Ud 8197f9c15b835301a3b98d5a6d58612d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #467: Expect: 100-continue and "final" status codes
Archived-At: <http://www.w3.org/mid/CACuKZqEfKFhCyDqeq_HpMfoG==jcx7xGifd=+qbUqErTZvBLjQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18113
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>
Sounds good. I wonder whether this mutual distrust between the client and the server is still valid today. RFC 2616 wrote in 1999 that some servers did not understand 100-continue. Is that still the case? I suspect that most deployed servers today do support 100-continue properly. Zhong Yu On Tue, May 28, 2013 at 1:03 AM, Mark Nottingham <mnot@mnot.net> wrote: > > On 18/05/2013, at 3:45 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote: > > > Hi Mark, I disagree with the change. > > OK. > > > The old text describes the intended use case - the client should wait > for a 100 response before sending the request body. The text then explains > the exceptional case - if the server is not known to be 1.1 compliant, the > client should not wait forever. > > > > Your proposed text emphasizes the exceptional case, making the intended > case rather hidden. I personally prefer the old text. > > I'd say that what's usable in practice is pretty far from the intent, and > furthermore, the intent isn't terribly clear. > > > One can argue that both texts have the same implication for > implementations, which must handle both the intended and exceptional cases > anyway. > > Right. > > > However there is one difference, which I think is critical. According to > the old text, if a server is 1.1 compliant, and the client *knows* that the > server is 1.1 compliant, client should wait indefinitely for a response > from server; it should not unilaterally decide to send the request body. > > Perhaps, but that's a very limited case; in practice, the only way it can > be sure of this knowledge is if it has previously received a HTTP/1.1 > response on the *same* connection. Since implementations often use a new > connection for a request with a body (since they're often unsafe, and the > connection could idle out in transit), this isn't terribly common, AIUI > (YMMV). > > > According to the proposed text, the client must send the request body > after very a short timeout. This is a new requirement on clients, which is > probably not damaging, but unjustified nevertheless. > > There aren't any new requirements in there; all of this text is only > describing semantics and giving implementation advice. What if we modify > the text slightly, e.g., > > """ > 100-continue > > * The request includes a payload body and, after sending the request > header section, the client will wait before some (possibly unbounded) > period of time before sending it, to give the server an opportunity to > reject the request with a final status code. The server can shorten the > wait time by sending a 100 (Continue) response. > """ > > With similar modifications as appropriate elsewhere? > > Cheers, > > > > > On Thu, May 16, 2013 at 9:47 PM, Mark Nottingham <mnot@mnot.net> wrote: > > Looking at this again, I think one of the problems is that people > misunderstand what e/c is for. > > > > The current definition of 100-continue in requests doesn't help: > > > > > 100-continue > > > > > > • The request includes a payload body and the client will wait > for a 100 (Continue) response after sending the request header section but > before sending the payload body. The 100-continue expectation does not use > any expect-params. > > > > > > < > https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.expect > > > > > > "will wait for" is misleading here; the client might send the body > before getting the 100 response. This should really say something like: > > > > """ > > 100-continue > > > > * The request includes a payload body and, after sending the request > header section, the client will wait before some period of time before > sending it, to give the server an opportunity to reject the request with a > final status code. The server can shorten the wait time by sending a 100 > (Continue) response. > > """ > > > > It then goes on: > > > > > The primary purpose of the 100 (Continue) status code (Section 6.2.1) > is to allow a client that is sending a request message with a payload to > determine if the origin server is willing to accept the request (based on > the request header fields) before the client sends the payload body. In > some cases, it might either be inappropriate or highly inefficient for the > client to send the payload body if the server will reject the message > without looking at the body. > > > > Again, I think this is misleading. It should say something like: > > > > """ > > The 100-continue expectation and 100 (Continue) status code (Section > 6.2.1) are useful when a request that has a large body might be rejected by > the server; for example, if the request requires authorization (ref to p7). > In these situations, clients will often pause between sending the request > headers and its body, to give the server an opportunity to refuse the > request. > > > > In cases where the request is successful, this can cause a needless > delay, as the client waits to time out (a typical period is one second). If > the client has send the 100-continue expectation, the server can use the > 100 (Continue) status code to indicate that the request is not going to be > rejected, thereby avoiding the remainder of this delay period. > > > > Note that this mechanism does not change the request message parsing > algorithm; in particular, whether or not a final response status code is > sent, the client still needs to send a complete request message. As such, > if a final status code is received, clients will often choose to close the > connection, rather than send a complete request (e.g., if it is > length-delimited). > > """ > > > > If we can agree on that, I think it'll help guide the rest of the > discussion here and in the other E/C related issues: > > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/458 > > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/468 > > > > Am I on track? > > > > Cheers, > > > > > > > > On 25/04/2013, at 3:06 AM, Willy Tarreau <w@1wt.eu> wrote: > > > > > On Wed, Apr 24, 2013 at 01:00:42PM -0400, Ken Murchison wrote: > > >>> 2. If the client receives a final status code instead of 100 > > >>> (Continue), it > > >>> should stop sending request body if it is doing so; it must close the > > >>> connection after the response is received. > > >> > > >> I don't understand point #2. If the client submits a request with > > >> Expect:100-continue, I would assume that the client MUST NOT send any > > >> part of the body until it receives 100 (Continue) from the server. If > > >> the server rejects the request based on the headers (with 412, 415, > 417, > > >> etc) there should be no body data in the pipe for either the client or > > >> server to worry about, correct? > > > > > > In fact the client can decide that it's been waiting too long for 100 > > > and decides to send anyway (because some old servers or intermediaries > > > do not know about Expect and will wait). > > > > > > So what is generally done is that the client sends the headers, waits a > > > bit then starts to send data if the server does not respond. > > > > > > Implementation of expect+100 seems to be a real mess at some places, > > > but when it works it prove to be quite useful. > > > > > > Willy > > > > > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > >
- p2: Expect: 100-continue and "final" status codes Mark Nottingham
- Re: p2: Expect: 100-continue and "final" status c… Zhong Yu
- Re: p2: Expect: 100-continue and "final" status c… Ken Murchison
- Re: p2: Expect: 100-continue and "final" status c… James M Snell
- Re: p2: Expect: 100-continue and "final" status c… Mark Nottingham
- Re: p2: Expect: 100-continue and "final" status c… Amos Jeffries
- Re: p2: Expect: 100-continue and "final" status c… Mark Nottingham
- Re: p2: Expect: 100-continue and "final" status c… Adrien W. de Croy
- Re: p2: Expect: 100-continue and "final" status c… Amos Jeffries
- Re: p2: Expect: 100-continue and "final" status c… Willy Tarreau
- Re: p2: Expect: 100-continue and "final" status c… Willy Tarreau
- Re: p2: Expect: 100-continue and "final" status c… Adrien W. de Croy
- Re: p2: Expect: 100-continue and "final" status c… Adrien W. de Croy
- Re: p2: Expect: 100-continue and "final" status c… Amos Jeffries
- Re: p2: Expect: 100-continue and "final" status c… Zhong Yu
- Re: p2: Expect: 100-continue and "final" status c… Ken Murchison
- Re: p2: Expect: 100-continue and "final" status c… Willy Tarreau
- Re: p2: Expect: 100-continue and "final" status c… Ken Murchison
- Re: p2: Expect: 100-continue and "final" status c… Willy Tarreau
- Re: p2: Expect: 100-continue and "final" status c… Daniel Stenberg
- Re: p2: Expect: 100-continue and "final" status c… Ken Murchison
- #467: Expect: 100-continue and "final" status cod… Mark Nottingham
- Re: #467: Expect: 100-continue and "final" status… Mark Nottingham
- Re: #467: Expect: 100-continue and "final" status… Willy Tarreau
- Re: #467: Expect: 100-continue and "final" status… Ken Murchison
- Re: #467: Expect: 100-continue and "final" status… Zhong Yu
- Re: #467: Expect: 100-continue and "final" status… Alex Rousskov
- Re: #467: Expect: 100-continue and "final" status… Mark Nottingham
- Re: #467: Expect: 100-continue and "final" status… Mark Nottingham
- Re: #467: Expect: 100-continue and "final" status… Willy Tarreau
- Re: #467: Expect: 100-continue and "final" status… Zhong Yu
- Re: #467: Expect: 100-continue and "final" status… Michael Sweet
- Re: Expect: 100-continue and "final" status codes Peter Occil
- Re: #467: Expect: 100-continue and "final" status… Willy Tarreau
- Re: #467: Expect: 100-continue and "final" status… Mark Nottingham