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

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.


-- 
Kenneth Murchison
Principal Systems Software Engineer 
Carnegie Mellon University

Received on Wednesday, 24 April 2013 17:35:43 UTC