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. On Wednesday, January 25, 2023 at 11:43:06 AM UTC-5 cshar...@chromium.org wrote: > 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 > <https://www.chromium.org/blink/launching-features/#implementations-of-already-defined-consensus-based-standards> > . > > 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? > > On Wed, Jan 25, 2023 at 9:52 AM 'Jiacheng Guo' via blink-dev < > blin...@chromium.org> wrote: > >> 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 >> >> -- >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. 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.
