You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
16843009 is (1*256*256*256)+(1*256*256)+(1*256)+1, also known as 1.1.1.1
If you paste the URL https://16843009 into 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)
curl: (60) SSL: no alternative certificate subject name matches target host name '16843009'
if curl is built with c-ares it instead says this:
curl: (6) Could not resolve host: 16843009
(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:
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
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#6863Closes#6871
I did this
curl https://16843009 -v
16843009 is
(1*256*256*256)+(1*256*256)+(1*256)+1
, also known as1.1.1.1
If you paste the URL
https://16843009
into 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: