Repository navigation
curl_easy_duphandle() drops conn_cache, negating any share handle association. #3592
Description
A share handle added to multiple easy handles should be sufficient to share connections between each easy, and indeed this works when each easy is created fresh and attached to a share.
However I observed that when the share handle is added to a prototype easy, then new easy handles are created from that prototype using curl_easy_duphandle(), the share appears to be "lost" and must be reattached.
Attaching the share to the easy handle produced by curl_easy_duphandle() works as expected.
I traced the cause to
Line 949 in 8bc5ceb
I did this
CURLSH *share = curl_share_init();
curl_share_setopt(share, CURLSHOPT_SHARE, CURL_LOCK_DATA_CONNECT);
CURL *base = curl_easy_init();
curl_easy_setopt(base, CURLOPT_SHARE, share);
curl_easy_setopt(base, CURLOPT_URL, "http://example.com");
// various other setopt calls
for(int i = 0; i < 10; ++i) {
CURL *handle = curl_easy_duphandle(base);
// child-specific setopt calls
curl_easy_perform(handle);
curl_easy_cleanup(handle);
}I expected the following
One network connection to example.com, page fetched 10 times in a pipline.
curl/libcurl version
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
operating system
Linux, Ubuntu 18.04
Activity
jay commentedon Feb 20, 2019
It says in the doc "The new handle will not inherit any state information, no connections, no SSL sessions and no cookies."
sgolemon commentedon Feb 21, 2019
Indeed, no idea how I missed that. :/
bagder commentedon Feb 21, 2019
After @sgolemon's report I read the man page again, and I can see how the clearing of the share-object association isn't immediately obvious - it is just inferred by that mention of "no state", but in the share handle case the state could also be seen as held by the share handle.
Of course we can argue that this is how the function is meant to work, but then I think we should also clarify this better in the documentation. We could also easily argue that a dup'ed handle should inherit the share options that the source had set. Personally, I'm sort of leaning towards the second one. One argument against that would possibly be that we've had this behavior for so long that changing this now risks introducing something weird for people and a safer route forward would be to clarify the docs around the existing functionality.
jay commentedon Feb 21, 2019
The doc seems pretty clear to me.
curl_easy_duphandle.3: clarify that a duped handle has no shares