Sorry, this was actually an error in my code :-( I always passed CURL_SOCKET_BAD to curl_multi_socket_action when I called it with CURL_CSELECT_IN. I have changed that to the correct socket descriptor and it's working now. It only worked by chance with the other proxies.

---
** [bugs:#1388] Another problem with proxy CONNECT and Connection: Keep-Alive**
**Status:** open
**Created:** Mon Jun 30, 2014 04:08 PM UTC by Marcel Raad
**Last Updated:** Thu Jul 03, 2014 02:58 AM UTC
**Owner:** Daniel Stenberg
This issue occurs in the same setup as [#1381], but with the correct proxy credentials preset with CURLOPT_PROXYUSERNAME and CURLOPT_PROXYPASSWORD.
I'm using libcurl 7.37.0 (built with SSPI on Windows) and I'm trying to establish a proxy tunnel through a squid 3.2.11 proxy. Both CURLOPT_HTTPPROXYTUNNEL and CURLOPT_CONNECT_ONLY are set to 1. The problem occurs only if the proxy does not send "(Proxy-)Connection: Close" together with "407 Proxy Authentication Required". It also does not occurs if I set exactly the authentication method required by the proxy (Basic) with CURLOPT_PROXYAUTH.
The problem is that after the proxy tunnel is established successfully, nothing ever happens (none of my callbacks are ever called) until the timeout occurs (no matter how high the values of CURLOPT_TIMEOUT and CURLOPT_CONNECTTIMEOUT are, I have tested with values between 3 and 60 seconds). Then my timeout triggers and curl_multi_info_read returns with CURLE_OPERATION_TIMEDOUT.
The big difference to a working proxy that sends "Proxy-Connection: Close" together with "407 Proxy Authentication Required" is that the working proxy ends up in the "if(data->easy_conn->bits.proxy_connect_closed)" case after the call to Curl_http_connect in the CURLM_STATE_WAITPROXYCONNECT case of multi_runsingle, while the failing proxy ends up in "else if((CURLE_OK == data->result) && (data->easy_conn->tunnel_state[FIRSTSOCKET] == TUNNEL_COMPLETE))".
The attached patch (against current git revision 1b6bc02fb926403f04061721f9159e9887202a96) fixes the problem for me, but I have no idea if it is correct or breaks other use cases.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.