Daniel et all,
There is an issue with current git version of Curl_proxyCONNECT() and
calling logic when using libcurl's multi interface...
Once the CONNECT command has been sent, in Curl_proxyCONNECT()
(http_proxy.c line 209) a single check is done to verify if we have
got a response to the CONNECT command. When the tunnel socket is
already readable negotiation logic following line 222 takes place. But
if we hav no answer yet from the proxy, Curl_proxyCONNECT() goes to
line 211 and returns CURLE_OK.
When multi interface is used and Curl_proxyCONNECT() returns CURLE_OK
with no response from CONNECT command, existing logic of multi
interface wrongly assumes that we have already got a positive response
for the CONNECT command and that 'proxy negotiation' has succeeded.
Current failures of test case #503 are showing this problem, although
due to timing variations #503 does not always fail given that some
times the response from the CONNECT command is already available and
then everything is fine.
Currently test 503 does not use the debug callback, but when I've
forced it to use one I was unable to repeat the issue. I suppose that
the time spent doing some logging is enough to allow the CONNECT
response from the proxy test server to arrive in time for existing
logic. In real world usage using a distant proxy would always trigger
I have done no testing rolling back commit 41b02378 given that I
believe it is a nice refactoring.
For testing purposes with existing logic I forced it to busy loop
around http_proxy.c line 209 until the tunnel socket was readable and
test case #503 succeeds with this horrible hack.
Daniel, would you mind fixing this issue? You may come with a simpler
solution to what I'm thinking right now which would involve additional
multi states and independent handlers for 'sending CONNECT', 'awaiting
response' and 'proxy authentication' and that could introduce
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2012-03-20