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/CAJQw1NxDGqGiUuK5f7vZpFFjVkk3sunobwTKeX-mN3T-mmX14g%40mail.gmail.com.
