Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: URL API accepts input with invalid IPv6 literals when configured without ENABLE_IPV6
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 14 Feb 2023 22:42:13 +0100 (CET)
On Tue, 14 Feb 2023, Brad Spencer via curl-library wrote:
> I started to add a test case with a fix, but then I realized that the
> desired outcome is unclear. Even when IPv6 support is disabled, the parsing
> code in the hostname_check() function in urlapi.c always looks for the '['
> and ']' surrounding an IPv6 literal, but then it skips some validation of
> the contents. As long as the content in between brackets is from the
> character set "0123456789abcdefABCDEF:.", it's allowed.
>
> My instinct was that all IPv6 literals would be rejected when IPv6 is
> disabled. But doing so is presumably a breaking change for someone.
>
> So, what is the expected behaviour of the URL parser when faced with a URL
> containing an IPv6 literal when IPv6 support is disable? If it's the
> current behaviour, is it worth adding a test case to demonstrate that it
> behaves as expected?
I think I prefer to rather go the other direction in the name of keeping the
behavior of the URL parser the same (ie improve the parser when IPv6 support
is disabled), independently of IPv6 support. An application might in fact
still want to be able to parse and validate URLs that contain IPv6 addresses
even when it can't actually use them to transfer data with libcurl.
To make that happen easiest, we would need to enable Curl_inet_pton and
Curl_inet_ntop() for IPv6 even when liburl cannot speak IPv6.
What do you think?
Date: Tue, 14 Feb 2023 22:42:13 +0100 (CET)
On Tue, 14 Feb 2023, Brad Spencer via curl-library wrote:
> I started to add a test case with a fix, but then I realized that the
> desired outcome is unclear. Even when IPv6 support is disabled, the parsing
> code in the hostname_check() function in urlapi.c always looks for the '['
> and ']' surrounding an IPv6 literal, but then it skips some validation of
> the contents. As long as the content in between brackets is from the
> character set "0123456789abcdefABCDEF:.", it's allowed.
>
> My instinct was that all IPv6 literals would be rejected when IPv6 is
> disabled. But doing so is presumably a breaking change for someone.
>
> So, what is the expected behaviour of the URL parser when faced with a URL
> containing an IPv6 literal when IPv6 support is disable? If it's the
> current behaviour, is it worth adding a test case to demonstrate that it
> behaves as expected?
I think I prefer to rather go the other direction in the name of keeping the
behavior of the URL parser the same (ie improve the parser when IPv6 support
is disabled), independently of IPv6 support. An application might in fact
still want to be able to parse and validate URLs that contain IPv6 addresses
even when it can't actually use them to transfer data with libcurl.
To make that happen easiest, we would need to enable Curl_inet_pton and
Curl_inet_ntop() for IPv6 even when liburl cannot speak IPv6.
What do you think?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-14