>
> > My plan is to make a Curl_http_connecting() in addition to
> > Curl_http_connect(), that would deal with the ssl negotiation, so that the
> > connection will be in the "CURLM_STATE_PROTOCONNECT" during this phase.
> >
> > is this the correct way, or should I try to extend Curl_http_connect() so
> > that the ssl is done when it completes. (and thus staying in
> > CURLM_STATE_WAITCONNECT a bit longer)?
>
> I'm not sure it makes any significant difference. Do you?

I don't, that's why I asked...

> Just note that Curl_ssl_connect() is called from numerous places and it is not
> easily fixed as described on all those places so you should probably make some
> (or most) of the existing calls remain blocking so that they can be fixed
> one-by-one later on.

Good idea.
As a first step, I split the big function in several ones and got the
while and select call out in an outer function. (no functional changes
from outside ssluse.c)
Here is a tentative patch for this first step.
Do you have any comments, since it's my first patch to curl?

Meanwhile, I proceed on making an other function that doesn't block to
be used from the multi interface.

> > Moreover I fail to understand in the simple case (ie not "multi" case) when
> > this function is called. (I mean, in url.c SetupConnection(),
> > curl_protocol_connect() is called and then the value of protocol_done is
> > ignored all the way to the initial caller and curl_protocol_connecting()
> > never seems to be called. how should it work in that case?
>
> Because, in the easy interface case, the singleipconnect() function simpy
> waits for the connect and doesn't return until it has connected or timed out
> so Curl_connecthost() (called from within ConnectPlease()) will return with
> the connection already established.

oh I understand now: there are places in the code with
(...state.used_interface == Curl_if_multi) that change behaviour
depending on the interface used.