On Thu, 13 Mar 2008, Raf Nulens wrote:

>> #2 - This site ignores this header and even when I experimented and had the
>> code wait for 30 seconds it never sent anything back, but libcurl had
>> to
>> continue sending its request-body only to get a 401 back after it had
>> completed it.
>>
>
> How do you mean the server never sent anything back? With the fake
> login/password it is never meant to send a 100 continue... It should
> respond with a 401 Authorization Required twice...

"should" being the operative word here. It's quite easy to see that this is
not the case here. This site sends back a 100 Continue immediately, even if
the user+password is completely made up (as it is in my case of course since I
have no legitiate user on this site). In fact, this is a very common broken
way of dealing with 100-continue. It effectively takes away the whole point of
having it.

This is a silly server/site that does this, it isn't libcurl's fault. It can
but adapt to the circumstances.

> So the 100-continue header is not the issue here, that header should be sent
> after the authentication succeeded which is never the case with our example
> (curl_easy_setopt(curl, CURLOPT_URL, "http://musicbrainz.org/ws/1/track/");).

No, the 100-continue header is sent in all posts where we want to let the
server tell us we're wrong before we proceed with sending the data so we
include it already in the first POST requests. And it's quite easy to see that
libcurl does it on this host too, as my example shows.

> Normally libcurl adds the 100-continue automatically when using POSTFIELDS,
> but disabling this header explicitly ("Expect:") does not alter the libcurl
> behavior.

Disabling 100-continue will only take away the only means the server would
have to deny the data to get posted when it hasn't been authorized properly.
So no, we don't expect removing the header to improve this situation.

>> So, I don't see how libcurl could do this any differently. Since you claim
>> a different behavior when you used CURLOPT_POSTFIELDS, did you actually use
>> the exact same target URL when you did that? Because I can't see how
>> libcurl can do much different given how the server responds.
>
> We're using the same target URL with the two scenarios.

And you're not seeing the 100-continue with the CURLOPT_POSTFIELDS approach?

Isn't it working fine with POSTFIELDS simply because rewinding the data and
doing a second post is done internally in this situation and you just haven't
provided any such callback for the read-callback way of posting?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html