To make it a bit clearer, change the proposed text =93the client = will wait=20 before some (possibly unbounded) period of time before sending it=94 to = =93the=20 client will wait before some (possibly unbounded) period of time sending = the=20 payload body=94.

--Peter

From: Zhong Yu

Sent: Tuesday, May 28, 2013 11:57 AM

To: Mark=20 Nottingham

Cc: Willy = Tarreau ; Ken = Murchison=20 ; HTTP Working=20 Group

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

Sounds good.

I wonder whether this mutual distrust = between=20 the client and the server is still valid today. RFC 2616 wrote in 1999 = that some=20 servers did not understand 100-continue. Is that still the case? I = suspect that=20 most deployed servers today do support 100-continue = properly.

Zhong=20 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>=20 wrote:

> Hi Mark, I disagree with the = change.

OK.

> The old text describes the intended use case = - the=20 client should wait for a 100 response before sending the request body. = The=20 text then explains the exceptional case - if the server is not known = to be 1.1=20 compliant, the client should not wait forever.
>
> Your = proposed=20 text emphasizes the exceptional case, making the intended case rather = hidden.=20 I personally prefer the old text.

I'd say that what's = usable in=20 practice is pretty far from the intent, and furthermore, the intent = isn't=20 terribly clear.

> One can argue that both texts have the same = implication=20 for implementations, which must handle both the intended and = exceptional cases=20 anyway.

Right.

> However there is one difference, which I = think is=20 critical. According to the old text, if a server is 1.1 compliant, and = the=20 client *knows* that the server is 1.1 compliant, client should wait=20 indefinitely for a response from server; it should not unilaterally = decide to=20 send the request body.

Perhaps, but that's a very limited = case;=20 in practice, the only way it can be sure of this knowledge is if it = has=20 previously received a HTTP/1.1 response on the *same* connection. = Since=20 implementations often use a new connection for a request with a body = (since=20 they're often unsafe, and the connection could idle out in transit), = this=20 isn't terribly common, AIUI (YMMV).

> According to the proposed text, the client = must send=20 the request body after very a short timeout. This is a new requirement = on=20 clients, which is probably not damaging, but unjustified=20 nevertheless.

There aren't any new requirements in there; = all of=20 this text is only describing semantics and giving implementation = advice. What=20 if we modify the text slightly, = e.g.,

"""
100-continue

* The=20 request includes a payload body and, after sending the request header = section,=20 the client will wait before some (possibly unbounded) period of time = before=20 sending it, to give the server an opportunity to reject the request = with a=20 final status code. The server can shorten the wait time by sending a = 100=20 (Continue) response.
"""

With similar modifications as = appropriate=20 elsewhere?

Cheers,

> On Thu, May 16, 2013 at 9:47 PM, Mark = Nottingham <mnot@mnot.net>=20 wrote:
> Looking at this again, I think one of the problems is = that=20 people misunderstand what e/c is for.
>
> The current = definition=20 of 100-continue in requests doesn't help:
>
> >=20 100-continue
> >
> = >       =95=20 The request includes a payload body and the client will wait for a 100 = (Continue) response after sending the request header section but = before=20 sending the payload body. The 100-continue expectation does not use = any=20 expect-params.
>
>
> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-http= bis/latest/p2-semantics.html#header.expect>
>
>=20 "will wait for" is misleading here; the client might send the body = before=20 getting the 100 response. This should really say something=20 like:
>
> """
> 100-continue
>
> * The = request=20 includes a payload body and, after sending the request header section, = the=20 client will wait before some period of time before sending it, to give = the=20 server an opportunity to reject the request with a final status code. = The=20 server can shorten the wait time by sending a 100 (Continue) = response.
>=20 """
>
> It then goes on:
>
> > The primary = purpose=20 of the 100 (Continue) status code (Section 6.2.1) is to allow a client = that is=20 sending a request message with a payload to determine if the origin = server is=20 willing to accept the request (based on the request header fields) = before the=20 client sends the payload body. In some cases, it might either be = inappropriate=20 or highly inefficient for the client to send the payload body if the = server=20 will reject the message without looking at the body.
>
> = Again, I=20 think this is misleading. It should say something = like:
>
>=20 """
> The 100-continue expectation and 100 (Continue) status = code=20 (Section 6.2.1) are useful when a request that has a large body might = be=20 rejected by the server; for example, if the request requires = authorization=20 (ref to p7). In these situations, clients will often pause between = sending the=20 request headers and its body, to give the server an opportunity to = refuse the=20 request.
>
> In cases where the request is successful, = this can=20 cause a needless delay, as the client waits to time out (a typical = period is=20 one second). If the client has send the 100-continue expectation, the = server=20 can use the 100 (Continue) status code to indicate that the request is = not=20 going to be rejected, thereby avoiding the remainder of this delay=20 period.
>
> Note that this mechanism does not change the = request=20 message parsing algorithm; in particular, whether or not a final = response=20 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=20 choose to close the connection, rather than send a complete request = (e.g., if=20 it is length-delimited).
> """
>
> If we can agree = on that,=20 I think it'll help guide the rest of the discussion here and in the = other E/C=20 related issues:
>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/458=
>  =20 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/468=
>
>=20 Am I on track?
>
> Cheers,
>
>
>
> = On=20 25/04/2013, at 3:06 AM, Willy Tarreau <w@1wt.eu> wrote:
>
> > = On Wed,=20 Apr 24, 2013 at 01:00:42PM -0400, Ken Murchison wrote:
> = >>> 2.=20 If the client receives a final status code instead of 100
> = >>>=20 (Continue), it
> >>> should stop sending request body = if it is=20 doing so; it must close the
> >>> connection after the = response=20 is received.
> >>
> >> I don't understand = point=20 #2. If the client submits a request with
> >>=20 Expect:100-continue, I would assume that the client MUST NOT send = any
>=20 >> part of the body until it receives 100 (Continue) from the=20 server. If
> >> the server rejects the request based = on the=20 headers (with 412, 415, 417,
> >> etc) there should be no = body=20 data in the pipe for either the client or
> >> server to = worry=20 about, correct?
> >
> > In fact the client can = decide that=20 it's been waiting too long for 100
> > and decides to send = anyway=20 (because some old servers or intermediaries
> > do not know = about=20 Expect and will wait).
> >
> > So what is generally = done is=20 that the client sends the headers, waits a
> > bit then = starts to=20 send data if the server does not respond.
> >
> >=20 Implementation of expect+100 seems to be a real mess at some = places,
>=20 > but when it works it prove to be quite useful.
> = >
> >=20 Willy
> >
> >
>
> --
> Mark=20 Nottingham   http://www.mnot.net/
>
>
>
><= BR>>

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