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.
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: Brad Spencer via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 14 Feb 2023 16:43:43 -0400
I happened to have a build of curl with ENABLE_IPV6 disabled. I passed
one of curl's own lib1560.c test URLs into the URL API, and I expected
to get the same behaviour that the test case expects (CURLUE_BAD_IPV6),
but instead it reports as parsing successfully and takes the whole
invalid IPv6 literal as the CURLUPART_HOST portion of the URL:
"http://[ab.be:1]/x" gives CURLUPART_HOST "[ab.be:1]"
"http://[ab.be]/x" gives CURLUPART_HOST "[ab.be]"
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?
Date: Tue, 14 Feb 2023 16:43:43 -0400
I happened to have a build of curl with ENABLE_IPV6 disabled. I passed
one of curl's own lib1560.c test URLs into the URL API, and I expected
to get the same behaviour that the test case expects (CURLUE_BAD_IPV6),
but instead it reports as parsing successfully and takes the whole
invalid IPv6 literal as the CURLUPART_HOST portion of the URL:
"http://[ab.be:1]/x" gives CURLUPART_HOST "[ab.be:1]"
"http://[ab.be]/x" gives CURLUPART_HOST "[ab.be]"
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?
-- Brad Spencer ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-14