Subject: Re: #467: Expect: 100-continue and "final" status codes
From: Ken Murchison <[email-masked]>
To: Mark Nottingham <[email-masked]>
Cc: Willy Tarreau <[email-masked]>, [email-masked]
Date: Fri, 17 May 2013 07:28:33 -0400
List-Id: <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