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

Hi Mark,

On Fri, May 17, 2013 at 12:47:27PM +1000, Mark Nottingham wrote:
> "will wait for" is misleading here; the client might send the body before
> getting the 100 response.

I think you made a good point here.

> 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.
> """

However, I wouldn't want server implementations to consider that a client
that is waiting too long before sending (or which does not send at all) is
not compliant, because I'm sure it's already used to send non-idempotent
requests over established connections.

Maybe we should try a variation of your text above, approximately like this
(I don't like my wording but it's just for the general idea) :

 * The request includes a payload body and, after sending the request header
 section, the client is willing to give the server an opportunity to reject
 the request with a final status code based on header inspection alone. The
 the client will then wait for the server to respond with an intermediary
 100 (Continue) status code before sending the payload, and may decide to
 send it anyway after a period of time which only depends on the client
 (typically one second).


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

Here we introduce a problem that will make one think that 100-continue
implies acceptation of the request, which is not true. I'd rather say :

  "... 100 status code to indicate that it needs to receive the full
   request to decide if it will accept it, ..."

> 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).
> """

This makes me notice something, shouldn't we suggest that 417 should be
accompanied with "connection: close" since there's always a risk that
the client started sending anyway ? Note that this would be a small
"should", not a normative one, which would just be a recommendation
to improve the communication between the two ends.

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

Yes I think so :-)

Willy

Received on Friday, 17 May 2013 05:36:52 UTC