Q:

`curl_easy_send` and `curl_easy_recv` over SSL: how to handle `CURLE_AGAIN`?

curl_easy_send and curl_easy_recv return CURLE_AGAIN when they can not send data immediatelly due to slow network connection.
It is possible to get socket wrapped by libcurl and call poll or select on that socket; if we call curl_easy_send, we'll wait until we can write more data (i. e. we'll use POLLOUT with poll), and for curl_easy_recv we'll wait until incoming data is available (i. e. we'll use POLLIN with poll).
This approach will not work for SSL connection, because even when we read SSL data, OpenSSL may need to write (for example, to perform new handshake). So, even we use curl_easy_send, we have no idea whether we have to use POLLIN or POLLOUT.
OpenSSL has SSL_want function for that issue. However, we need pointer to SSL session if we want to call SSL_want.
I tried to use CURLINFO_TLS_SSL_PTR to get OpenSSL session pointer; this method returns null always however when we use CURLOPT_CONNECT_ONLY.
So, how to handle CURLE_AGAIN in a correct way with curl_easy_send and curl_easy_recv over SSL?

A:

I found solution myself finally. I don't understand for what reason libcurl team implemented CURLINFO_TLS_SSL_PTR in such a way that it returns nullptr even connection is made over SSL and Curl object still contains the SSL session pointer, but can not return it in a correct way. I can only hope that they will fix this issue in future versions and libcurl users will not have to invent bicycle.
Fortunatelly, we can get SSL session (at least for OpenSSL) in following way:

Use CURLOPT_SSL_CTX_FUNCTION to be able to get SSL context when Curl will create it.
Use SSL_CTX_set_info_callback with this context to be able to intercept new SSL session creation event.
Use this SSL session with SSL_want function to handle CURLE_AGAIN in a correct way.

