Bugs item #2963679, was opened at 2010-03-04 21:37
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2963679&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: hang
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenny To (kto-vmware)
Assigned to: Daniel Stenberg (bagder)
Summary: Tunnel proxy with multi interface may hang

Initial Comment:
Version: 7.19.5
OS: Windows XP Pro
Test: HTTP (not HTTPS) POST with multi interface while using CURLOPT_HTTPPROXYTUNNEL

On a high level, I observed that this would hang for about a minute before performing the request.

Running wireshark on the proxy, I saw that the client running curl would send the CONNECT request, the proxy would connect to the requested host and respond, then instead of sending the POST request as expected, the client did nothing for a while.

Putting some logging in the routine we supply as CURLMOPT_SOCKETFUNCTION showed that curl asked for CURL_POLL_REMOVE on the socket after the CONNECT response was received and just before we start to hang. Eventually the timeout set by CURLMOPT_TIMERFUNCTION was invoked, and the POST request was performed.

Debugging, I saw that the CURL_POLL_REMOVE happens after we move from CURLM_STATE_WAITCONNECT to CURLM_STATE_PROTOCONNECT. The code updating the sockets being supervised saw that the handler->proto_getsock for HTTP doesn't exist, so we should no longer supervise this socket. This leads me to believe that from CURLM_STATE_WAITCONNECT, we should actually have gone to CURLM_STATE_WAITDO/CURLM_STATE_DO instead of CURLM_STATE_PROTOCONNECT because the protocol connection phase has nothing to do.

I saw that the reason we didn't is because in CURLM_STATE_WAITCONNECT, despite Curl_is_connected() returning TRUE, the connection's bits.tcpconnect was FALSE. Curl_protocol_connect() saw this and decided that the protocol's connect phase wasn't done even though we did have a TCP connection and the proxy had already responded to the CONNECT request. Since CURLM_STATE_WAITCONNECT had (connected && !protocol_connect), it moved to CURLM_STATE_PROTOCONNECT.

I looked around for places where we mark bits.tcpconnect, and there didn't seem to be one along the path where, instead of the TCP connect finishing quickly enough, we had to wait for it and go to CURLM_STATE_WAITCONNECT. I made Curl_is_connected() update bits.tcpconnect if it sees that the TCP connect completed successfully. This solved my problem, and I confirmed that I hit the new code. A trivial patch is included.

Please let me know if this patch makes conceptual sense and whether my description of the problem is plausible. For now, we will probably start using this patch internally. Also, I understand if you'd like an isolated test case, but I'm not sure if I'll have time to make one.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2010-03-23 23:01

Message:
Thanks for a fine report and fine research. Your logic seems fine and the
patch is small and neat. I'll commit this!

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2963679&group_id=976
Received on 2010-03-23