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 <[email protected]> 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 < > [email protected]> 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFvZe97aGdvtWr82eUWXsNS%3DRGsq5tuK7D8bWH%2Bx36v8w%40mail.gmail.com.
