People have asked for NTLM support on wxCurl, which supports PUT/POST,
so I could probably add that option in reasonably soon, which might
facilitate testing. I've been using PUT with digest authentication,
and having good luck with the current method.

CKO

On Thu, 4 Nov 2004 17:10:17 +0100 (CET), Daniel Stenberg
<daniel-curl_at_haxx.se> wrote:
> 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
>

-- 
Casey O'Donnell
RPI STS Department - Graduate Student
http://homepage.mac.com/codonnell/
http://homepage.mac.com/codonnell/wxsync/
http://homepage.mac.com/codonnell/wxblogger/