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

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