Daniel,

It looks like libcurl treats the various stages of NTLM challenge response as a redirect to the same URL.
Instead of trying to reproduce the issue using NTLM, we can use a HTTP server which responds with circular redirects.

HTTP GET request to URL (A) responds with a 302 redirect to URL (B) after a timeout of 9s.
HTTP GET request to URL (B) responds with a 302 redirect to URL (A) after a timeout of 9s.

curl easy handle options:
CURLOPT_FOLLOWLOCATION: 1
CURLOPT_MAXREDIRS: -1
CURLOPT_TIMEOUT: 10

This is what happens inside libcurl:
STATE: DO => DO_DONE => WAITPERFORM => PERFORM
data->req.newurl is set to (B)
state changes to CURLM_STATE_CONNECT, progress.t_startsingle is reset to "now".

All expiration timers are now relative to the new progress.t_startsingle, and curl_easy_perform never returns.

According to docs, CURLOPT_TIMEOUT is the "maximum time in seconds that you allow the libcurl transfer operation to take".
Technically a redirect is a new transfer operation, but an NTLM challenge response "redirect" is the same transfer operation, isn't it?

I can think of the following solutions:
1. TIMER_STARTSINGLE be set at the end of CURLM_STATE_INIT, rather than the start of CURLM_STATE_CONNECT.
Will doing so affect wild card transfers?

2. A new "CURLOPT_EASY_PERFORM_TIMEOUT" which looks at the transfer operation in a holistic view and compares against SessionHandle's progress.start for expiration.

--
Paras. 		 	   		  
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html