Hi all,

This is my first post, I'm a curl newbie...

We are experiencing problems with curl_easy on the mac talking to an
IIS server that uses NTLM authentication.

I think this may be a known bug, as follows in Known Bugs, but it is
not an auth failure so I'm not sure.

37. Having more than one connection to the same host when doing NTLM
   authentication (with performs multiple "passes" and authenticates a
   connection rather than a HTTP request), and particularly when
using the
   multi interface, there's a risk that libcurl will re-use a wrong
connection
   when doing the different passes in the NTLM negotiation and thus
fail to
   negotiate (in seemingly mysterious ways).

We have linked to the curl library that comes with Mac OS X; we've
tried this with Tiger (10.4.x) and Leopard (10.5.x) and it acts the
same.

A decapitated version of the captured HTTP traffic, with notes and
comments, is below; since are not building curl we're not able to
break into it.

My questions are:
(1) can anyone tell for sure that is this another manifestation of
the known bug above, and is there any workaround that we can use?
(2) is there any more testing or capturing I can do to help diagnose
this issue?

Thanks
Rudi Sherry

Adobe Systems Inc
345 Park Ave
San Jose, CA 95116

----------------------------------------------------------------
We have a 260K file that we are trying to PUT, but I'll represent it
by a file whose contents is:

++ABCDEFGHIJKLMNOPQRSTUVWXYZ--

We use curl_easy_init() with no extra options.

Captured traffic:

PUT /directory/file.pdf HTTP/1.1
Host: webdav.server.com
Accept: */*
Content-Length: 30

++ABCDEFGHIJHTTP/1.1 401 Access denied
Connection: close
Date: Fri, 25 Apr 2008 21:04:36 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
MicrosoftSharePointTeamServices: 6.0.2.6568
X-Powered-By: ASP.NET
Content-type: text/html

(html text error message from server)

KLMNOPQR

notice three things:
   1. we have overridden the "Expect: 100" header, but we've found
that doesn't make any difference; the problem behavior is the same
   2. the server responds with 401 before the entire request is
uploaded (!) (this happens even if we don't turn off Expect: 100: we
get back 100 to the original request headers, then we start
uploading, then we get a 401 in the middle of uploading before the
bytes are finished).
   3. the client sends some more bytes after getting the 401
(KLMNOPQR) but eventually stops before the end of the file.

...curl_easy_perform() returns 401 to us, and we call
curl_easy_cleanup() then get a new handle with curl_easy_init() and
set up the same request, this time with NTLM in the headers. We do
this cleanup/init because we've discovered that IIS servers don't
like the no-auth request then NTLM-auth request in the same connection.

We start the request with curl_easy_perform() on the new handle, and
the capture shows:

PUT /directory/file.pdf HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=
Host: webdav.server.com
Accept: */*
Content-Length: 0

notice:
   1. since we have turned off Expect: 100, curl sends content-length
0 (we found this empirically)
   2. the NTLM auth is the first part of the handshake

Reply:

HTTP/1.1 401 Unauthorized
Content-Length: 1539
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
TlRMTVNTUAACAAAACAAIADgAAAAGgokCQNI745f8HtQAAAAAAAAAALgAuABAAAAABQLODgAA
AA9BRE9CRU5FVAIAEABBAEQATwBCAEUATgBFAFQAAQAQAEMATwBMAEwAQQBCAFEARQAEADIA
YQBkAG8AYgBlAG4AZQB0AC4AZwBsAG8AYgBhAGwALgBhAGQAbwBiAGUALgBjAG8AbQADAC4A
QwBPAEwATABBAEIAUQBFAC4AYwBvAHIAcAAuAGEAZABvAGIAZQAuAGMAbwBtAAUAIABnAGwA
bwBiAGEAbAAuAGEAZABvAGIAZQAuAGMAbwBtAAAAAAA=
MicrosoftSharePointTeamServices: 6.0.2.6568
X-Powered-By: ASP.NET
Date: Fri, 25 Apr 2008 21:04:36 GMT

(contents are html error page)

We then send:

PUT /directory/file.pdf HTTP/1.1
Authorization: NTLM
TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAAAAABwAAAABwAHAHAAAAAVABUAdwAAAAAA
AAAAAAAABoKJAn
+b2ltxRqcaAAAAAAAAAAAAAAAAAAAAAN1HFzZ0fEvp9HrDKan0dSmyrtfDqlertHJzaGVycn
lyc2hlcnJ5LW9mZmljZS1tYWN0ZWw=
Host: webdav.server.com
Accept: */*
Content-Length: 30

STUVWX++ABCDEFGHIJKLMNOPQRSTUV

notice:
  1. "STUVWX" seems to be a continuation of the truncated post of the
first PUT of the curl handle on which we already called
curl_easy_cleanup(), but it doesn't finish it. My guess is that it's
some sort of buffer inside a socket that is being emptied, which
makes me think it's using the other connection.
  2. The resulting WebDAV resource "file.pdf" at the server side
contains exactly what we sent: "STUVWX++ABCDEFGHIJKLMNOPQRSTU", so we
know IIS isn't eating the bytes.

Then we get a mystery reply:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Fri, 25 Apr 2008 21:04:36 GMT
Connection: close
Content-Length: 35

<h1>Bad Request (Invalid Verb)</h1>

notice:
   1. What the heck? I don't know what this is about, I don't know
if it's a curl issue or what. I've seen some google traffic that
implies IIS is eating the Content-Length bytes; this may be a
response to the very first PUT w/o NTLM auth, but I'm not sure.

More notes:

We turned on verbose, and CURL claims for the final upload that it's
only uploading the bytes of the file; it seems to know nothing about
those extra "STUVWX" bytes.
Received on 2008-05-07