Re: [PATCH] always multi v5
Date: Wed, 16 Jan 2013 21:16:03 +0100
On Tue, Jan 15, 2013, Daniel Stenberg wrote:
> I run this and compare the traces and that tells Curl_proxyCONNECT() seems
> to not be working entirely correct for you, although I haven't been able to
> pinpoint why/how.
> To me it looks as if in your case it doesn't properly detect the end of the
> response (headers) so it continues to wait and then eventually the
> connection gets closed and it gets upset.
> Can you sprinkle some debug logs in there to see if you can figure it out?
Attached trace1059 shows that first call to Curl_proxyCONNECT()
returns CURLE_OK without having actually connected to the proxy,
awaiting to be called again. No problem here. socket is actually
connected but it has not detected activity yet.
The problem is in Curl_protocol_connect()
Curl_protocol_connect() calls Curl_proxy_connect() which is the one
calling Curl_proxyCONNECT() and getting a CURLE_OK with low level
transport connection established but without having received a single
bit from the proxy.
Afterwards Curl_protocol_connect() calls ftp_connect() the
protocol-specific connect() procedure and this is the one that is
reading the proxy CONNECT response. eeeek!!
That's the reason why trace shows an FTP state change from STOP to
WAIT220 inmediately after first Curl_proxyCONNECT() that returns
CURLE_OK, and it is the FTP handler the one that reads the http proxy
So it seems that somehow we should avoid calling the protocol specific
connect() in Curl_protocol_connect() until the proxy connection has
been fully established.
- application/octet-stream attachment: trace1059