W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

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

From: Ken Murchison <murch@andrew.cmu.edu>
Date: Fri, 17 May 2013 07:28:33 -0400
Message-ID: <51961461.2080800@andrew.cmu.edu>
To: Mark Nottingham <mnot@mnot.net>
CC: Willy Tarreau <w@1wt.eu>, ietf-http-wg@w3.org
On 05/16/2013 10:47 PM, Mark Nottingham wrote:
> 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 is an important point that I completely missed from any reading of 
2616 and the current httpbis.  I assumed that if the server responded 
with a final status code before sending 100-continue, that the client 
would not send the body.

If I read your proposed text properly, the only way for a client to 
avoid sending the body of a failed conditional request while maintaining 
a persistent connection is to send the request using e/c and te/chunked, 
and just send a zero-length chunk after receiving the final response 
code.  Correct?

Having the ability to not send a large body if its going to be rejected 
seems like a useful feature to me, but maybe its not actually 
implemented in the wild.

Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Friday, 17 May 2013 11:29:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC