On Sun, 14 Jan 2018, Michael Kilburn via curl-library wrote:

> My assumption is that no TLS-related data is sent until TCP handshake is
> done (i.e. related ACK received, or whatever it is -- I don't remember
> details).

That is correct - in the general case.

> But I could be wrong -- I vaguely remember reading about some optimization
> where connection was "opening" immediately,

TFO (TCP Fast Open) allows for data to be sent already in the handshake, but
unless you ask for that, libcurl won't try to use TFO so that's not the case
here.

When you get a TLS error returned, we can assume libcurl did a successful TCP
connection handshake and continued to do the TLS negotiation. The VERBOSE
output from libcurl will probably also confirm this.

>> Yes. Typically you'd have a multi handle which shares the connection cache.
>
> Hmm... I need to look into this. Something tells me that having cache of
> easy handles (protected by mutex) isn't the most efficient solution either.

It mostly depends on what the alternative is. In a lot of cases it is
certainly the moste efficient solution, like when the alternative means
setting up an entirely new TLS connection instead of re-using one and
"wasting" some microseconds on a mutex.

But we only provide the means, it is up to every user to deem what is the best
way for their use case.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html