> 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.

I apologize for that, not sure what happened, perhaps I left it with rich text formatting or something. Hopefully this one goes through okay, if not I will have to try to use a different mail tool.

>>> 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.
>
> What issue is it that occurrs exactly that is timing dependent?

The issue is that without the delay, the tunnel to the proxy server is not correctly established, and the call fails with a 407 error code. The sort of good news is that I don't think it is directly related to the NTLM code, I think it is with the code that establishes the proxy tunnel.

The issue is in http.c, in the CURL_proxyCONNECT function. There is data from the proxy server response that is not getting properly dealt with. On the last "go round" with the proxy server libcurl reads in the remainder of the proxy auth response from the previous round. The reason why the delay in the debug callback is affecting it is because the complete proxy server responses are able to be retrieved in one read with the delay.

You can clearly see this in the work2.txt and nowork2.txt files I have attached. I added an info debug showing the number of bytes retrieved on each go round. In work2.txt larger chunks are being retrieved up front (probably the entire proxy server response), where in nowork2.txt, smaller chunks are being returned (my guess is just the initial headers).

I was looking at the code to try and address it myself, but am fearful of making changes to the code as I am not sure what other impacts it could have. My guess is that there needs to be some looping to clear out any remaining socket buffer on keep-alive proxy connections between authorization calls.

_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE