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

Re: p2: Expect: 100-continue and "final" status codes

From: Ken Murchison <murch@andrew.cmu.edu>
Date: Wed, 24 Apr 2013 15:20:48 -0400
Message-ID: <51783090.5020103@andrew.cmu.edu>
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
Willy Tarreau wrote:
> On Wed, Apr 24, 2013 at 01:34:51PM -0400, Ken Murchison wrote:
>> On Wed, 24 Apr 2013 13:06:38 -0400, Willy Tarreau 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.
>> Fair enough. But I would expect that a compliant 1.1 server would respond
>> with 100 (Continue) or failure pretty quickly -- well within the client's
>> "wait" interval.     Given that RFC 2616 is over a decade old, I would like
>> to think that any 1.1 implementation would be compliant with the Expect
>> behavior or should be deprecated. 
>> Unless we are worried about Expect:100-continue being sent to a 1.0 server,
>> allowing a client to start sending a body in the absence of 100 (Continue)
>> seems like a bad idea to me.  But if this behavior IS needed a client should
>> at least wait several seconds or something longer than the expected roundtrip
>> time.
>> Am I way off base here?  I'm not privy to all of the history of HTTP.  I only
>> started developing our CalDAV server a couple of years ago.
> No you're perfectly right, but you forgot about the messy case where the 1.1
> client sends via a 1.0 gateway to an 1.1 server and the 1.0 gateway needs to
> validate the contents before passing the request :-)

Yes, ignorance on my part.  If the client-side special handling needs to 
stay because of 1.0 intermediaries, then so be it.  But I don't think 
there should be any wiggle room for 1.1 servers at this point in the game.

Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Wednesday, 24 April 2013 19:21:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC