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.html
