Using IPV6 host in CURLOPT_RESOLVE or --resolve results in a malformed/illegal address error

[rgret-dev]

I did this

On the command line:

curl -v --resolve "2606:4700:4700::1111:443:2606:4700:4700::1111" https://[2606:4700:4700::1111]
curl -v --resolve "2606:4700:4700::1111:443:[2606:4700:4700::1111]" https://[2606:4700:4700::1111]
curl -v --resolve "[2606:4700:4700::1111]:443:2606:4700:4700::1111" https://[2606:4700:4700::1111]
curl -v --resolve "[2606:4700:4700::1111]:443:[2606:4700:4700::1111]" https://[2606:4700:4700::1111]

which all resulted in the following error:

* Resolve address '4700::1111:443:[2606:4700:4700::1111]' found illegal!
* Couldn't parse CURLOPT_RESOLVE entry '2606:4700:4700::1111:443:[2606:4700:4700::1111]'!
curl: (49) Couldn't parse CURLOPT_RESOLVE entry '2606:4700:4700::1111:443:[2606:4700:4700::1111]'!

With libcurl (and the same combinations with square brackets above):

#include <curl/curl.h>
#include <stdio.h>

int main(void) {
  CURL *curl = curl_easy_init();
  struct curl_slist *host = curl_slist_append(NULL, "2606:4700:4700::1111:443:2606:4700:4700::1111");

  curl_version_info_data *version_data = curl_version_info(CURLVERSION_NOW);
  printf("libcurl version: %s\n", version_data->version);

  if (curl) {
    curl_easy_setopt(curl, CURLOPT_RESOLVE, host);
    curl_easy_setopt(curl, CURLOPT_URL, "https://[2606:4700:4700::1111]");

    CURLcode res = curl_easy_perform(curl);
    if (res != CURLE_OK) {
      printf("error: %s", curl_easy_strerror(res));
    }

    curl_easy_cleanup(curl);
  }

  curl_slist_free_all(host);
}

results in:

libcurl version: 7.81.0
error: Malformed option provided in a setopt

I expected the following

The IPV6 host section to be parsed correctly since 1.1.1.1:443:1.1.1.1 works as expected.

curl/libcurl version

curl 7.81.0
libcurl 7.81.0

operating system

Linux desktop 5.15.0-131-generic #141-Ubuntu SMP Fri Jan 10 21:18:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

[bagder]

I suppose we never properly considered using this option to replace IP addresses.

[jay]

I don't know why anyone would do that

[jay]

@rmg-x maybe --connect-to can do what you want? it matches by string so the ip address would have to match exactly as in the url

curl -v --connect-to "[2606:4700:4700::1111]::[2607:f8b0:4006:816::200e]:" https://[2606:4700:4700::1111]

[rgret-dev]

This was found while working on the Ladybird browser project which uses libcurl in the backend to handle requests. It has its own DNS resolver capability so that, in the future, users have full control over that process rather than delegating to an underlying/system resolver. It's slightly odd but on each request, CURLOPT_RESOLVE is specified so the resolution is guaranteed to be coming from the internal resolver. I'm not a maintainer of Ladybird so I'm not speaking on behalf of that project, but that is how I understand it to work currently.

Given the fact that IPV4 addresses work correctly in this case, I'd expect the IPV6 equivalent to as well.

[bagder]

so the resolution is guaranteed to be coming from the internal resolver

Sure, for a name that gets resolved such reasoning makes sense but for a numerical IP address, it really does not.

Still, a bug.

[rgret-dev]

Sure, for a name that gets resolved such reasoning makes sense but for a numerical IP address, it really does not.

Sorry for being unclear, I was just explaining how it was found. I definitely don't think this is a normal or common use case 😅

I appreciate the quick responses and PR to address this!