The message below was originally rejected by your Spam Filter, but was re-sent through webmail. It was blocked for: F5_Unwanted_To_Address: curl-library_at_lists.sourceforge.net.

---------------------------------------------------------------------------------------------------

I tried replying to this before but for some reason it never appeared... so here goes.

And if we
would send data then, does the server simply discard that and continue the
autentication as if no data had been sent?
- Yes. Imagine a case where a sever accepts anonymous users and allows a PUT.

A client has no idea (nor could it) that a particular server even requires authentication to access a resource prior to the initial attempt. So, a client should sent the full and correct request. If a server needs auth to process it properly it will let the client know at that time with a 401.

If the client sends the server a \"real\" request the first time out the worst case scenario is that the server tosses out the request if a client cannot provide the right credentials in response to a challenge. Essentially the same thing curl would do today except the server would also be tossing out the body and not just the header.

On Monday, January 19, 2004, at 01:23 AM, Daniel Stenberg wrote:

(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rl-library&m7403508511869&w 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
-------------------------------------------------------
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
--bf29e63b3bcb4d2597c4670e01cec5a92--
-------------------------------------------------------
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