bad --resolve syntax should fail the transfer

[gunhu]

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]

Agreed. I think that makes perfect sense!

[gunhu]

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

[daenney]

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.