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

bad --resolve syntax should fail the transfer #7170

Closed
gunhu opened this issue Jun 2, 2021 · 3 comments
Closed

bad --resolve syntax should fail the transfer #7170

gunhu opened this issue Jun 2, 2021 · 3 comments

Comments

@gunhu
Copy link
Contributor

@gunhu gunhu commented Jun 2, 2021

I did this

When using curl with --resolve option if the format isn't respected. curl is falling back silently on the default hostname resolution (/etc/hosts/, DNS, etc..)

Eg:

$ curl --resolve 443:curl.se:151.101.66.49 https://curl.se -v

  • Couldn't parse CURLOPT_RESOLVE entry '443:curl.se:151.101.66.49'!
  • Trying 151.101.66.49...

I expected the following

$ curl --resolve 443:curl.se:151.101.66.49 https://curl.se -v

  • Couldn't parse CURLOPT_RESOLVE entry '443:curl.se:151.101.66.49'!

And then exit with an error message but no automagic with a fallback.

curl/libcurl version

$ curl -V
curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

operating system

$ uname -a
Darwin FRLPMC1134 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64

@bagder bagder changed the title curl and --resolve option bad --resolve syntax should fail the transfer Jun 2, 2021
@bagder
Copy link
Member

@bagder bagder commented Jun 2, 2021

Agreed. I think that makes perfect sense!

@bagder bagder self-assigned this Jun 2, 2021
@gunhu
Copy link
Contributor Author

@gunhu gunhu commented Jun 2, 2021

Like we said on IRC, let me take a look and submit a PR

@daenney
Copy link

@daenney daenney commented Jun 2, 2021

I ran into a similar case where I used domain:port:other-domain instead of domain:port:ip resulting in a similar silent fallback that threw me for a loop. The fact that it needs an IP is explained in the man page so this was mostly on me not reading it correctly (and makes sense if you think of it like an /etc/hosts patch). But it would've been nice if curl had stopped me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants