Intent to remove: Shortened IPv4 addresses in the URL

[Jiacheng Guo]

Hi everyone

I plan to remove the shortened IPv4 address support in the URLs such as 127.1 and 192.168.1.

WPT failures are reported because of this:

<a>: Setting <http://example.net/>.host = '[::1.2.3.]'

!EQ("http://example.net/", "http://[::102:3]/")

I've added an UMA to collect data about whether people are inputting such kinds of addresses in the omnibox.

Data in beta showed that only 0.04% of IPv4 addresses input in the omnibox URL are in this form.

We'd like to remove the support as a part of the URL interop.

Jiacheng Guo

[Charles Harrison]

Hey Jiacheng,

Did you mean for this to be an official intent? If so, I think it should have a chromestatus.com entry as per the guidelines here.

One more question: I assume from the mention of WPTs that you plan on changing this across the whole web platform, not just for top level navigations. Why do you think measuring just the omnibox metrics is sufficient for measuring the breakage from this change? Should we try to measure this at a lower level like in //url?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%40mail.gmail.com.

[Matt Menke]

Is that the only test removing this behavior breaks?  I'm not seeing test cases for simple IPv4 expansion cases, like just "http://127.1/".  I also notice that in Firefox, http://127.1 is mapped to http://127.0.0.1/, but http://[::1.2.3.] is not treated as a URL, so it's unclear to me if the provided test case is suggesting browsers should standardize on not supporting shortened URLs at all, or only in the case of IPv4 addresses embedded in IPv6 addresses.

The URL standard (https://url.spec.whatwg.org/) in fact explicitly says that the host parser should map "0" to "0.0.0.0" and "0xFFFFFFFF" should be mapped to "255.255.255.255" (for "special" schemes, which includes http and https).  The IPv4 parser in that doc also continues to support strings with fewer than 4 components.

While I'm all for removing support for these, I think there's spec work to be done here first.

[Avi Drissman]

Are you talking about IPv4 alone? Or only IPv4 in IPv6, like your examples that have brackets?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb33ba97-8088-409e-9c26-ccb1a9ca10b9n%40chromium.org.

[Harald Alvestrand]

The two addresses here are IPv6 addresses, not IPv4 addresses, as evidenced by the :: marker.

The first form is an IPv6 with embedded IPv4, and it has a trailing dot that I do not understand at all, I think it's not legal syntax.

The second form is two numbers in hex, so the byte value of the last 4 bytes should be 0x01020003. Which would be equivalent to the first one if there was no trailing dot, because that's the shape of an IPv4 Class B address, where the last number represents a 16-bit number, not an 8-bit number.

I'm not sure what you mean by "shortened IPv4 address" - if you mean IPv4 addresses with less than 3 dots (class B and class A addresses, when classes existed) -  I think that they are indeed rarely used, since modern IPv4 networks aren't allocated in classes any more.

I would want to check with other browser vendors on whether they think it's worth deprecating this syntax - it's been standardized since IPv4 was introduced, so it's a LONG tradition that you are breaking, and unless we agree with the others first, we're breaking compatibility.

Harald

--

[Harald Alvestrand]

Checking the spec is always wise:

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 says that only the 4-digit form of IPv4 address should be supported (4 numbers from 0-255). There is no trailing dot, so that one is illegal.

The RFC goes on to say ( https://www.rfc-editor.org/rfc/rfc3986#section-7.4 ) about the non-4-number form:

"These additional IP address formats are not allowed in the URI syntax

   due to differences between platform implementations.  However, they
   can become a security concern if an application attempts to filter
   access to resources based on the IP address in string literal format.
   If this filtering is performed, literals should be converted to
   numeric form and filtered based on the numeric value, and not on a
   prefix or suffix of the string form."

So we've been inconsistent with the IETF URI spec since at least 2005, and it may be time to fix the bug.

But properly!

[Harald Alvestrand]

Personal opinion:

Disallowing the trailing dots should not cause any issues at all; I think we should just do this (as a bug fix).

Since the W3C standard and the IETF standard agree on only permitting the 4-number form embedded in IPv6 addresses, i think it's a safe change to police that restriction too.

The shortening of pure IPv4 literal addresses is the only case where it might be reasonable to measure usage; I suppose that's the one you've been measuring already.

On Thu, Jan 26, 2023 at 6:33 AM Jiacheng Guo <g...@google.com> wrote:

Much thanks for your advice and checking the standard for the correct behavior.

I'd like to provide some more detailed context here.

The proposed change is a part of the URL section in interop 2023. Currently our URL parser treats [::1.2.3.] as shortened IPv4 addresses embedded in IPv6 and this is causing a bunch of WPT test failures.

The URL RFC requires IPv4 address to consist of concisely four parts.

I revisited the URL web standard and it found that it allows shortened IPv4 addresses without trailing dots and disallows embedding them into IPv6 addresses.

Currently in chrome:

- We are not validating the trailing dots in IPv4 and IPv4-embedded IPv6 addresses.

- We allow shortened IPv4 addresses and embedding them into IPv6 addresses.

My new proposal is to check the trailing dots in IP addresses and remove support for embedding shortened IPv4 addresses in IPv6 addresses.

Does this make sense? Would you advise additional usage metrics to be collected?

Much appreciated

Jiacheng Guo

[Jiacheng Guo]

Much thanks for your advice and checking the standard for the correct behavior.

I'd like to provide some more detailed context here.

The proposed change is a part of the URL section in interop 2023. Currently our URL parser treats [::1.2.3.] as shortened IPv4 addresses embedded in IPv6 and this is causing a bunch of WPT test failures.

The URL RFC requires IPv4 address to consist of concisely four parts.

I revisited the URL web standard and it found that it allows shortened IPv4 addresses without trailing dots and disallows embedding them into IPv6 addresses.

Currently in chrome:

- We are not validating the trailing dots in IPv4 and IPv4-embedded IPv6 addresses.

- We allow shortened IPv4 addresses and embedding them into IPv6 addresses.

My new proposal is to check the trailing dots in IP addresses and remove support for embedding shortened IPv4 addresses in IPv6 addresses.

Does this make sense? Would you advise additional usage metrics to be collected?

Much appreciated

Jiacheng Guo

On Thu, Jan 26, 2023 at 7:29 AM Harald Alvestrand <h...@google.com> wrote:

[Domenic Denicola]

Hi Jiacheng,

I think this all seems on the right track. Two things:

1. You need to use the actual Intent to Ship template for such changes, generated by the chromestatus.com tool. That will help clear things up because it contains well-labeled fields for things like motivation, spec, tests, interop risk, what other browsers do, etc.
2. This discussion would be a lot clearer for everyone involved if you clearly referenced the standard we intend to follow. That is https://url.spec.whatwg.org/ , specifically the https://url.spec.whatwg.org/#concept-ipv6-parser algorithm. Some people on this thread are talking about IETF or W3C specs, but those are not what Chrome considers when implementing URL parsing, nor what the browser community has agreed upon working toward with Interop 2023. So I think bringing those other specs into the discussion is just muddying the waters.
   
   The behavior there is very clearly specified, so I'd hope your intent to ship could be something like "Intent to Ship: URL Standard-compatible IPv6 host parser", and then go further to explain that the one backward-incompatible change this involves is cases like ___. In other words, talking about "removing shortened IPv4 addresses" is harder to understand than "implement standards-compliant IPv6 host parser".

Hope this helps,

Domenic

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVF7yPsUn9973GrRifEmqGT1OgJg%3DwVMc_8CdzeTi%2BmgFQ%40mail.gmail.com.