(For a reason unknown to me, I never got Jacob's follow up in this thread, the
post available here:
http://marc.theaimsgroup.com/?l=curl-library&m=107403508511869&w=2. I'm
quoting from that web archive in order to continue this thread.)

> Unfortunately, that patch seems to make things worse. Watching curl with a
> packet sniffer it does send the PUT with the Content-Length header set
> correctly but it does not follow the transmission of the header with any
> data.

Of course! It can't send any data until it has completed the authentication.
This is the main reason to start with why it didn't send the content-length
header.

> Once the server receives the header it waits for the content to follow
> effectively bringing everything to a full stop.

... but the authentication is not complete, how can it expect data to be sent?

> I was able to hack a fix for this that is not optimal but works. I removed
> the line that overrode the request to make it a get. I did need to change
> the CURLOPT_READFUNCTION though to reset the buffer once it had been read so
> that it could be read again. This was to make sure the right thing happened
> when curl sent the buffer more than once during NTLM authentication for
> example. Again, not the right fix but it did workaround the problem.

I honestly don't understand what your server expects from the client. Why
would the client send data before the authentication is verified? And if we
would send data then, does the server simply discard that and continue the
autentication as if no data had been sent?

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn