On Thu, 22 Jan 2015, 无有先生 wrote:
There are two kinds of state will cause the SSL certification:
CURLM_STATE_WAITPROXYCONNECT and CURLM_STATE_WAITCONNECT. I think you mean
CURLM_STATE_WAITPROXYCONNECT using non blocking, and CURLM_STATE_WAITCONNECT
using blocking mode, processing the remaining work.
No I don't. Both states should be handled as non-blocking as possible as both
states are made to support that. But as we don't yet support TLS to the proxy,
we know that there will not be any TLS handshake involvde in the proxy connect
process.
The blocking one I mentioned would be for the data channel establishment.
However, if through the HTTPS proxy to access the FTPS server
That's a HTTP proxy not HTTPS, right?
if the CURLM_STATE_WAITPROXYCONNECT state SSL authentication is successful,
the FTPS server will give the client returns "220 FTP server ready" message,
The 220 is a response from the remote server, so that means it connected
through both the proxy and the remote server. It is not supposed to happen
within the WAITPROXYCONNECT state. As soon as we connect the proxy tunnel, we
should switch to WAITCONNECT and there we should connect to the remote server.
Isn't that what's happening?
and under the condition of CURLM_STATE_WAITCONNECT, there will be re second
SSL certification, and the "220 FTP server ready" message will use second
authentication failure.
The only cert verification for the control channel should be in WAITCONNECT.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
