On Thu, 30 Jun 2011, Steven Parkes wrote:

>> Why should it? The whole purpose of Expect: 100-continue is to avoid having
>> to send the request body in a case like this when the server can tell the
>> client at once that the request (and body) isn't wanted.

> as related to auth. Moreover, I don't see anything in rfc2616 that would
> indicate the behavior for 404 should be any different than that for 401. It
> specs the behavior for "a final status code".

I completely agree, the 100 response code is the key here, not what follows.

Looking at this a bit closer, it seems libcurl does indeed do this wrong. It
does have the appropriate handling of a 401/407 response (when it will either
continue sending the data if it is small enough and it can rewind or if it is
NTLM used) but it isn't generic enough to also cater for other 4xx errors.

This is a bug, no doubt. I guess it hasn't been noticed before because proper
100-continue treatment is so rare, and servers such as Apache sends back 100 +
404 for this case.

I've figured out a way to repeat rougly this case with the test suite, and
I'll see what I can come up with in terms of a proper fix...

Thanks for your detailed report and explanations!

--
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html