Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

duphandle doesn't preserve CURLOPT_RESOLVE #2485

Closed
ernstp opened this issue Apr 12, 2018 · 4 comments
Closed

duphandle doesn't preserve CURLOPT_RESOLVE #2485

ernstp opened this issue Apr 12, 2018 · 4 comments

Comments

@ernstp
Copy link

ernstp commented Apr 12, 2018

I did this

struct curl_slist *host = curl_slist_append(NULL, "foo.net:80:127.0.0.1");

CURL *curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);
curl_easy_setopt(curl, CURLOPT_RESOLVE, host);

CURL *c2 = curl_easy_duphandle(curl);
curl_easy_setopt(c2, CURLOPT_URL, "http://foo.net/");
curl_easy_perform(c2);

I expected the following

I expected my CURLOPT_RESOLVE to still have effect on c2. However it does not.
It's interesting that the message
"Added foo.net:80:127.0.0.1 to DNS cache"
never appears so it looks like it's neither done for the first curl handle nor c2.

Moving the setopt for RESOLVE to c2 works.

I can't really find anything in the documentation that would hint to this behaviour.

curl/libcurl version

curl 7.55.1 (x86_64-pc-linux-gnu) libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
Release-Date: 2017-08-14
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 UnixSockets HTTPS-proxy PSL

operating system

Linux/Ubuntu

bagder added a commit that referenced this issue Apr 12, 2018
Verified in test 1502 now

Fixes #2485
Reported-by: Ernst Sjöstrand
@bagder
Copy link
Member

bagder commented Apr 12, 2018

Thanks!

My tentative fix above also adds a test for this. I think the only thing to add is to use caution with this since now both handles use the same list so you must make sure to not free the list until both are done with it!

@ernstp
Copy link
Author

ernstp commented Apr 12, 2018

Right, but that caution applies in a lot of other similar cases as well, right? Like adding headers etc. So it shouldn't surprise anyone...

@bagder
Copy link
Member

bagder commented Apr 12, 2018

Absolutely, it just struck me when I did the change and modified the test code to use this...

@bagder
Copy link
Member

bagder commented Apr 12, 2018

Thanks!

@bagder bagder closed this as completed in 2b126cd Apr 12, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants