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

[Daniel Stenberg <[e-mail]>]

On Wed, 24 Apr 2013, Ken Murchison wrote:

> 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.

curl/libcurl uses "Expect: 100-continue" by default when it sends larger 
POSTs. As a result, it is probably one of the most commonly disabled headers 
in curl requests. A significant amount of servers have problems with it, 
although I can't back this statement up with any numbers.

The nature of the problems can vary from blatantly refusing to respond when 
the header is present (or just return an error), to just not being aware of it 
and thus the wait-time is just wasted time that makes the operation much 
slower.

curl waits one second for a response before it continues anyway, and it is of 
course possibly too short in some edge cases but I don't think I've ever seen 
any problems due to that.

-- 

  / daniel.haxx.se