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/
>
>
>
>