Re: #467: Expect: 100-continue and "final" status codes

Michael Sweet <msweet@apple.com> Tue, 28 May 2013 16:06 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 CBCB421F9769 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 09:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.519
X-Spam-Level:
X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.079, 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 3YedQyJIg-HM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 09:06:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3C21F9128 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 09:06:14 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhMOv-0002Pv-HP for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 16:05:29 +0000
Resent-Date: Tue, 28 May 2013 16:05:29 +0000
Resent-Message-Id: <E1UhMOv-0002Pv-HP@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <msweet@apple.com>) id 1UhMOf-0002CJ-Tz for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 16:05:13 +0000
Received: from mail-out.apple.com ([17.151.62.49]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.72) (envelope-from <msweet@apple.com>) id 1UhMOV-0006Kn-VZ for ietf-http-wg@w3.org; Tue, 28 May 2013 16:05:13 +0000
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_loFM56cszMIVudDSOgZLdw)"
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNI0062TNB4ZLM0@mail-out.apple.com> for ietf-http-wg@w3.org; Tue, 28 May 2013 09:04:19 -0700 (PDT)
X-AuditID: 11807157-b7f706d0000006c6-20-51a4d581901d
Received: from [17.153.23.147] (Unknown_Domain [17.153.23.147]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id F0.1C.01734.285D4A15; Tue, 28 May 2013 09:04:19 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <CACuKZqEfKFhCyDqeq_HpMfoG==jcx7xGifd=+qbUqErTZvBLjQ@mail.gmail.com>
Date: Tue, 28 May 2013 12:04:16 -0400
Cc: Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>, Ken Murchison <murch@andrew.cmu.edu>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <A92880B4-EFDC-4695-B759-9A48959A2A67@apple.com>
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> <CACuKZqEfKFhCyDqeq_HpMfoG==jcx7xGifd=+qbUqErTZvBLjQ@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUiOFN8sm7z1SWBBs/+cFscbpnFZLH+02NG iyPfYi0W3NzOZHF8/hxGi6lH/7E4sHmcnr6f2eN1q5DH1pM/2Dx2zrrL7rFx8XdWj6Pz9rMG sEVx2aSk5mSWpRbp2yVwZWxawFlwYi5jRW/vFaYGxjmNjF2MnBwSAiYSl89MYoKwxSQu3FvP 1sXIxSEk0Mskce7tb7AiYQEHiaXXV4MV8QroSVz79pUdxGYWSJD4eGoVK4jNJqAm8XtSH5jN KRAosef3DDCbRUBVYvO3f1D1kxkl5s51gphjI7Hg2Ek2EFtI4A+TxPO1niC2iICyxLGby6AO kpV4/fwNywRGvllIVs9CshrC1pZYtvA1M4RtIPG08xUWcX2JN+/mMC1gZFvFKFCUmpNYaaKX WFCQk6qXnJ+7iREU8g2F4TsY/y2zOsQowMGoxMM7IXtxoBBrYllxZe4hRgkOZiUR3ksrlwQK 8aYkVlalFuXHF5XmpBYfYpTmYFES5/05d1agkEB6YklqdmpqQWoRTJaJg1OqgfF025JvIuZT ler15sXfUM/q9O5asf/GpLqtv24WJjo6HN3JtNpCU2Ozm/f5RPX1XMtmrtWc5jG1kU1aXDQ5 7Jr6xEp/xev7uzpdNl32/e7fuqBB5s5OvdTVN0Mm7Q9NzvhjfIHv0lpj5fCcK2vbGd6Iahpd 1xPlVjux9yyLb67tWe7ZWQKn3ZVYijMSDbWYi4oTAeT+kyB1AgAA
Received-SPF: pass client-ip=17.151.62.49; envelope-from=msweet@apple.com; helo=mail-out.apple.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UhMOV-0006Kn-VZ 00f0e205588ef59b62d33b8ae8179dec
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/A92880B4-EFDC-4695-B759-9A48959A2A67@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18114
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>

You'll still find many embedded HTTP servers that do not honor the Expect header.  CUPS has explicit timeout code on the client side for this since it affects (far too) many IPP printers... :(

But things are improving compared to 5 years ago...


On 2013-05-28, at 11:57 AM, Zhong Yu <zhong.j.yu@gmail.com>; wrote:

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair