3 ms·

The "zone index" they mentioned can make for even more unwieldy URLs than described here. A browser doesn't have to accept: http://[fe80::1ff:fe23:4567:890a%et

The "zone index" they mentioned can make for even more unwieldy URLs than described here. A browser doesn't have to accept: http://[fe80::1ff:fe23:4567:890a%eth0]/ http://[fe80::1ff:fe23:4567:890a%eth0]/ Because of the ambiguity around '%', the browser may require: http://[fe80::1ff:fe23:4567:890a%25eth0]/ http://[fe80::1ff:fe23:4567:890a%25eth0]/ I'm not sure how common this would actually be—neither of these URL forms are valid in Firefox or Chrome on my machine today. Source: https://tools.ietf.org/html/rfc6874#section-3 https://tools.ietf.org/html/rfc6874#section-3

WorldMaker 6y ago
As the article points out the zone identifiers are primarily for making sure you are sending packets out on the right device (network adapter) and extremely rarely play into receiving data, so it would be extremely uncommon/unlikely to see zone identifiers in URLs because presumably they would only make sense, pending some unspecified future usage, for diagnostics on a single device (as the zone identifiers mostly don't "leave" a specific device; they aren't advertised externally, there is no way to query them, etc. Explicitly per RFC 4007 that defines zone identifiers, "The zone indices are strictly local to the node."). (Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.) (Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)

WorldMaker 6y ago

As the article points out the zone identifiers are primarily for making sure you are sending packets out on the right device (network adapter) and extremely rarely play into receiving data, so it would be extremely uncommon/unlikely to see zone identifiers in URLs because presumably they would only make sense, pending some unspecified future usage, for diagnostics on a single device (as the zone identifiers mostly don't "leave" a specific device; they aren't advertised externally, there is no way to query them, etc. Explicitly per RFC 4007 that defines zone identifiers, "The zone indices are strictly local to the node."). (Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.) (Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)