On Aug 28th, 2007 Daniel Stenberg wrote:
 
>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: http://curl.haxx.se/lxr/source/docs/examples/debug.c) 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. 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. 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. It looks like the final '200' header from the proxy server is being missed (according to Ethereal it is being sent), and libcurl is returning the earlier 407 proxy authentication code. I have had this problem with both the official release build (7.16.4) and the daily build from Aug 20th. All my code is using the easy mode libcurl functions, with OpenSSL and Windows SSPI turned on in the library.
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE