cURL / Mailing Lists / curl-library / Single Mail


RE: NTLM Proxy Authentication and SSL

From: Daniel Stenberg <>
Date: Thu, 30 Aug 2007 12:39:40 +0200 (CEST)

On Tue, 28 Aug 2007, Paul Mecklar wrote:

Oh boy, did your reply end up broken to pieces in that mail! I've tried to
restore it manually, so anything is still weird it is probably my fault.

>> NTLM works identically over SSL or not so I fail to see how that changes
>> anything really... Instead of using ethereal/wireshark to see what happens
>> over the wire, I suggest you use CURLOPT_DEBUGFUNCTION (feel free to copy
>> some code from this example:
>> to dump the complete
>> incoming and outgoing headers and data. Then verify that it truly gets a
>> 200 back but thinks it is a 407 as then it must be some major confusion on
>> libcurl's behalf that needs to be addressed.

> It appears that the issue is a timing one. I wrote a quick test app using
> the debug.c code, and I could not reproduce the issue. However, as soon as I
> disabled the debugging, the issue occurred again.

What issue is it that occurrs exactly that is timing dependent?

> It also occurred if I reduced the amount of debug info that was being
> displayed. In my original code (which did have debugging turned on, but the
> formatting was much simpler), adding a 100ms sleep during the debug callback
> also fixed the issue I was having. Attached are two files, work.txt and
> nowork.txt. They show the debug output of libcurl in both situations.

Yes, but they lack a lot of details such as the incoming headers etc so they
really don't reveal much to me.

> The only difference in the code between work.txt and nowork.txt is that
> work.txt has the 100ms sleep delay in the callback. If I had to guess (and I
> do because I know next to nothing about the internals of libcurl), it
> appears something is non-blocking when it should be blocking.

Well, let's assume that there's something in libcurl that blocks then. Why on
earth would that break NTLM for you in this particular case?

I don't think there is anything that "blocks" libcurl in the NTLM handling, at
least not within libcurl's source code.

> All my code is using the easy mode libcurl functions, with OpenSSL and
> Windows SSPI turned on in the library.

Do note that SSPI means the NTLM header stuff is bascially done by windows
itself and not by libcurl's NTLM code.

  Commercial curl and libcurl Technical Support:
Received on 2007-08-30