Storing ipv4 addresses as 32bit numbers is common so I can certainly see a use for that.

I'm not sure why you were downvoted. If this is true, it seems like it would save developers a conversion step when making a request.

I would guess because the point of the number parsing is to end-up producing that final 32-bits value. If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser.

Like the article mention, supporting obscure features just makes it more likely that they can be exploited for nefarious purposes. It's not worth saving typing 4-5 characters from times to times.

Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.

> If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser.

There is a point when the only interface to that program is via text. You still have to convert the 32-bit value to text, but there's a difference between that and converting it to IPv4's dot notation. The former is simpler.

> It's not worth saving typing 4-5 characters from times to times.

I don't think the main users of the feature are people manually typing those addresses.

> Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.

But then it wouldn't be a valid IP.

> > Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.

> But then it wouldn't be a valid IP.

127.1.0.0 is a perfectly valid IP address. The loopback range is a /8.

You're right. I got confused a bit.

I agree. The article even says that these odd formats are used to bypass filters but cannot pinpoint why BSD 4.2 added support for them in 1983.

It hints that certificate validation fails in some cases, but that seems even more niche. What applications are using certs with IP-in-CN anyway in 2021? Shouldn't any IPs be in the "typed" SAN extension?

Commit is here: https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...

Firefox will try and convert decimals (and perhaps numbers of other bases) into an IPv4 representation. I discovered this the other day after accidentally inputting “1” into the address bar.

Since IPv4 addresses are natively a 32-bit integer at the level of BSD sockets, it makes sense to allow curl to accept them without having it be re-parsed back out into a dotted-quad. Many tools and databases will store addresses natively this way. Let's say you were writing a script to take that information and probe it with curl; convenient to just printf("https://0x%x", ip_address), you know?

I use them fairly often, but I'm a network engineer.

I odo ccasionally use the (already-mentioned)

  $ ping 1.1

  $ 10.1

variants, but I use "these obscure formats" more frequently when dealing with 4-byte ASNs (cf. [0], for example).

--

[0]: https://ccieblog.co.uk/bgp/bgp-4-byte-as-numbers

I had the same reaction, especially after Daniels paragraph on how the more obscure formats can and has been used by bypass validation filters.

But, I'm also happy for having curl be more consistent with itself, so that it has the same behaviour on developer workstation and in production, since I'd imagine most pen-testing happens by developers locally.

Syslinux, specifically PXELINUX: https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#Conf...

Quite nifty I'd say.

I'm also slightly disappointed because I thought they either drop support or introduce a strict mode that can be used to disable support for esoteric formats.

Most *nixes accept a lot of these weird formats in many contexts.