cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: PUT with digest auth, sends HEAD #1054859

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Thu, 4 Nov 2004 17:10:17 +0100 (CET)

On Tue, 2 Nov 2004, Jamie Lokier wrote:

> The correct thing, according to RFC2616 and discussions on ietf-http-wg, is
> this:

Thanks for your clarifying words. I feel a bit lost in this... mess.

Unfortunately, all this is very theoretical for me as I have no access to any
servers that allows me doing easy testing of these things.

Based on the lack of bug reports and feedback from others, I can only guess
that most of the current weirdo-code works for most users or that we hardly
have any users that do these things.

> So here's how the contents are not sent twice:
>
> 1. Server responds with 401 asking for authentication, and closes
> the connection.
> 2. Client never sends request body, because auth response is received
> before the delay. Or, if client has already started, it can abort
> after reading the whole response.
> 3. Client opens a new connection and this time authenticates.

This is ugliness. We can't do persistent connections and auth at the same
time. But if this the only way, I will obey.

> (Note that Curl was buggy before: it didn't send the request body in this
> case (i.e. no "100 Continue" received) but send the next request's headers.
> That's not valid HTTP).

It was buggy before and it is buggy now... This area of RFC2616 and family is
like a maze.

> That works fine for Basic or Digest authentication. You'll notice that
> those don't in any way depend on maintaining a persistent connection. IETF
> HTTP is fundamentally stateless, and never depends on persistent
> connections.
>
> The only problem area is NTLM, which requires the connection to be
> maintained.

Yes, NTLM is the one that has caused me the most headache and since I prefer
using the same method for all multi-pass methods, this is where we are now: in
the wrong corner. ;-)

> NTLM is contrary to RFC2616 - precisely because it depends on a persistent
> connection. Therefore, you won't find the answer to this in RFC2616 or
> other HTTP RFCs.
>
> Instead, if there is any answer to what's right for NTLM, it'll by found
> elsewhere - in Microsoft documentation, for example.
>
> Thus I expect the right answer (for NTLM) is: What does the Microsoft client
> do for NTLM auth POST and PUT requests?

Yes, this would indeed be _very_ interesting to figure out.

Any user out there who know of a Microsoft tool that do POST/PUT with NTLM? If
so, snooping on the traffic to figure out what it does would be *very*
interesting.

Any insight on other tools/libraries that do PUT/POST and NTLM would be
interesting as well.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html
Received on 2004-11-04