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 On Thu, Jan 26, 2023 at 6:00 PM 'Harald Alvestrand' via blink-dev < blink-dev@chromium.org> wrote: > 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 >> >> On Thu, Jan 26, 2023 at 7:29 AM Harald Alvestrand <h...@google.com> wrote: >> >>> 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! >>> >>> >>> >>> On Wed, Jan 25, 2023 at 11:22 PM Harald Alvestrand <h...@google.com> >>> wrote: >>> >>>> 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 >>>> >>>> >>>> On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev < >>>> blink-dev@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+unsubscr...@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/CAOqqYVF7yPsUn9973GrRifEmqGT1OgJg%3DwVMc_8CdzeTi%2BmgFQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVF7yPsUn9973GrRifEmqGT1OgJg%3DwVMc_8CdzeTi%2BmgFQ%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/CAM0wra-F6h9GM1XVaF3Qp7bSY04DrUMc9Gq9eEqh1q%2BScXteyg%40mail.gmail.com.
