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.
