numerical host name not normalized #6863
Closed
Assignees
Labels
Comments
bagder
added a commit
that referenced
this issue
Apr 8, 2021
When the host name in a URL is given as an IPv4 numerical address, the address can be specified with dotted numericals in four different ways: a32, a.b24, a.b.c16 or a.b.c.d and each part can be specified in decimal, octal (0-prefixed) or hexadecimal (0x-prefixed). Instead of passing on the name as-is and leaving the handling to the underlying name functions, which made them not work with c-ares but work with getaddrinfo, this change now makes the curl URL API itself detect and "normalize" host names specified as IPv4 numericals. The WHATWG URL Spec says this is an okay way to specify a host name in a URL. RFC 3896 does not allow them, but curl didn't prevent them before and it seems other RFC 3896-using tools have not either. Host names used like this are widely supported by other tools as well due to the handling being done by getaddrinfo and friends. I decided to add the functionality into the URL API itself so that all users of these functions get the benefits, when for example wanting to compare two URLs. Also, it makes curl built to use c-ares now support them as well and make curl builds more consistent. The normalization makes HTTPS and virtual hosted HTTP work fine even when curl gets the address specified using one of the "obscure" formats. Test 1560 is extended to verify. Fixes #6863
bagder
added a commit
that referenced
this issue
Apr 8, 2021
When the host name in a URL is given as an IPv4 numerical address, the address can be specified with dotted numericals in four different ways: a32, a.b24, a.b.c16 or a.b.c.d and each part can be specified in decimal, octal (0-prefixed) or hexadecimal (0x-prefixed). Instead of passing on the name as-is and leaving the handling to the underlying name functions, which made them not work with c-ares but work with getaddrinfo, this change now makes the curl URL API itself detect and "normalize" host names specified as IPv4 numericals. The WHATWG URL Spec says this is an okay way to specify a host name in a URL. RFC 3896 does not allow them, but curl didn't prevent them before and it seems other RFC 3896-using tools have not either. Host names used like this are widely supported by other tools as well due to the handling being done by getaddrinfo and friends. I decided to add the functionality into the URL API itself so that all users of these functions get the benefits, when for example wanting to compare two URLs. Also, it makes curl built to use c-ares now support them as well and make curl builds more consistent. The normalization makes HTTPS and virtual hosted HTTP work fine even when curl gets the address specified using one of the "obscure" formats. Test 1560 is extended to verify. Fixes #6863 Closes #6871
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did this
curl https://16843009 -v16843009 is
(1*256*256*256)+(1*256*256)+(1*256)+1, also known as1.1.1.1If you paste the URL
https://16843009into your favorite browser you will see that they handle it. The WHATWG URL Spec says this is an okay way to specify a host name in a URL. (RFC 3896 does not.) curl accepts the host name and sort of half-works with it.If curl is built without c-ares it says this (or similar)
if curl is built with c-ares it instead says this:
(because c-ares doesn't do the funny conversion of the number into separate octets)
Presumably this will also do it wrong for plain HTTP or other protocols that want the host name passed on since curl will use '16843009' as host name everywhere while it probably should use "1.1.1.1" ...
I expected the following
That it would get the contents of that HTTPS server written to stdout.
curl/libcurl version
All versions
operating system
All OSes
Credit
Someone reported during a recent live-stream of mine. I'm sorry I didn't properly write down your name to give you proper credit for this.
The text was updated successfully, but these errors were encountered: