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

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