curl-library
Re: PUT with digest auth, sends HEAD #1054859
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.htmlReceived on 2004-11-04