4 ms·

> Fixing the human readable address encoding would help Yes! They need an alternate encoding form that distills to the same addresses. My machines Link-local

> Fixing the human readable address encoding would help Yes! They need an alternate encoding form that distills to the same addresses. My machines Link-local IPV6 address is "fe90::6329:c59:ad67:4b52%8" If I try to paste that into the address bar in Edge or Chrome (with the https://) it does an internet search on that string! No way around it. I have to do workarounds like: "http://fe90::6329:c59:ad67:4b52%8.ipv6-literal.net:8081/ http://fe90::6329:c59:ad67:4b52%8.ipv6-literal.net:8081/ All to test the IPv6 interface on a web server I'm running on my local machine.

pocksuppet 6mo ago
An IPv6 literal hostname in a URL must be surrounded by square brackets.
- fortran77 6mo ago
  Chrome and Edge still do a search on it in my default search engine even with [] https://[fe80::5ad6:9567:26b7:763b%18]:8081/ Even Hacker News doesn't think it's a link
  - deleted 6mo ago
    [deleted]
  - 1718627440 6mo ago
    On Mozilla Firefox after reenabling the separation into URL and searchbar it reports: "Invalid URL – Hmm. That address doesn’t look right. \n Please check that the URL is correct and try again." What does the '%' mean in there?
    - pocksuppet 6mo ago
      For link-local addresses, the part after % identifies the link. It's platform-specific - in Linux it's the interface name and in Windows it's an ID number.
Dagger2 6mo ago
Blame the WHATWG for that. They're the reason that v6 addresses in URLs are such a mess. http://[fe90::6329:c59:ad67:4b52%8]:8081/ should work, but doesn't because they refuse to allow a % there. (This is really damned frustrating, because link-locals are excellent for setting up routers or embedded machines, or for recovering from network misconfigurations.) If it's on the same machine then just use http://[::1]:8081/. Dropping the interface specifier (http://[fe90::6329:c59:ad67:4b52]:8081/) works if the OS picks a default, which some will. curl seems to be happy to work. Or just use one of the non-link-local addresses on the machine, if you have any. The other frustrating part of this is that it makes it impossible to come up with your own address syntax. An NSS plugin on Linux could implement a custom address format, and it's kind of obvious that the intention behind the URL syntax is that "[" and "]" enter and exit a raw address mode where other URI metacharacters have no special meaning. In general you can't syntax validate the address anyway because you don't know what formats it could be in (including future formats or ones local to a specific machine), so the only sane thing to do is pass the contents verbatim to getaddrinfo() and see if you get an error. But no, they wrote the spec to only allow a subset of v6 addresses and nothing else. I very much didn't test it, but this patch might do the job on Firefox (provided there's no code in the UI doing extra validation on top): --- a/netwerk/base/nsURLHelper.cpp +++ b/netwerk/base/nsURLHelper.cpp @@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) { bool net_IsValidIPv6Addr(const nsACString& aAddr) { - return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr); + return true; }

pocksuppet 6mo ago

An IPv6 literal hostname in a URL must be surrounded by square brackets.

fortran77 6mo ago
Chrome and Edge still do a search on it in my default search engine even with [] https://[fe80::5ad6:9567:26b7:763b%18]:8081/ Even Hacker News doesn't think it's a link
- deleted 6mo ago
  [deleted]
- 1718627440 6mo ago
  On Mozilla Firefox after reenabling the separation into URL and searchbar it reports: "Invalid URL – Hmm. That address doesn’t look right. \n Please check that the URL is correct and try again." What does the '%' mean in there?
  - pocksuppet 6mo ago
    For link-local addresses, the part after % identifies the link. It's platform-specific - in Linux it's the interface name and in Windows it's an ID number.

Dagger2 6mo ago

Blame the WHATWG for that. They're the reason that v6 addresses in URLs are such a mess. http://[fe90::6329:c59:ad67:4b52%8]:8081/ should work, but doesn't because they refuse to allow a % there. (This is really damned frustrating, because link-locals are excellent for setting up routers or embedded machines, or for recovering from network misconfigurations.) If it's on the same machine then just use http://[::1]:8081/. Dropping the interface specifier (http://[fe90::6329:c59:ad67:4b52]:8081/) works if the OS picks a default, which some will. curl seems to be happy to work. Or just use one of the non-link-local addresses on the machine, if you have any. The other frustrating part of this is that it makes it impossible to come up with your own address syntax. An NSS plugin on Linux could implement a custom address format, and it's kind of obvious that the intention behind the URL syntax is that "[" and "]" enter and exit a raw address mode where other URI metacharacters have no special meaning. In general you can't syntax validate the address anyway because you don't know what formats it could be in (including future formats or ones local to a specific machine), so the only sane thing to do is pass the contents verbatim to getaddrinfo() and see if you get an error. But no, they wrote the spec to only allow a subset of v6 addresses and nothing else. I very much didn't test it, but this patch might do the job on Firefox (provided there's no code in the UI doing extra validation on top): --- a/netwerk/base/nsURLHelper.cpp +++ b/netwerk/base/nsURLHelper.cpp @@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) { bool net_IsValidIPv6Addr(const nsACString& aAddr) { - return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr); + return true; }