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

-------------------------------------------------------
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
Received on 2004-01-31