27234 2014-11-04 16:41:59 +0000 Support IPv6 link-local addresses? 2017-05-25 05:49:26 +0000 1 1 1 Unclassified WHATWG URL unspecified All All RESOLVED WONTFIX http://code.google.com/p/chromium/issues/detail?id=70762 P2 normal Unsorted 25946 1 annevk annevk anthony mike rubys sascha-web-www.w3.org simon.sapin sleevi VYV03354 w3bugs sideshowbarker+urlspec oldest_to_newest 114496 0 annevk 2014-11-04 16:41:59 +0000 There appears to be some interest to support this in browsers: https://bugzilla.mozilla.org/show_bug.cgi?id=700999 There is an RFC that updates RFC 3986 for this: https://tools.ietf.org/html/rfc6874#section-2 122583 1 annevk 2015-08-13 08:23:06 +0000 I believe Ryan told me we should not do this. 122603 2 sleevi 2015-08-14 01:46:22 +0000 Yes, we're especially not keen to support these in Chrome and have repeatedly decided not to. The platform-specific nature of <zone_id> makes it difficult to impossible to validate the well-formedness of the URL (see https://tools.ietf.org/html/rfc4007#section-11.2 , as referenced in 6874, to fully appreciate this special hell). Even if we could reliably parse these (from a URL spec standpoint), it then has to be handed 'somewhere', and that opens a new can of worms. Even 6874 notes how unlikely it is to encounter these in practice - "Thus, URIs including a ZoneID are unlikely to be encountered in HTML documents. However, if they do (for example, in a diagnostic script coded in HTML), it would be appropriate to treat them exactly as above." Note that a 'dumb' parser may not be sufficient, as the Security Considerations of 6874 note: "To limit this risk, implementations MUST NOT allow use of this format except for well-defined usages, such as sending to link-local addresses under prefix fe80::/10. At the time of writing, this is the only well-defined usage known." And also "An HTTP client, proxy, or other intermediary MUST remove any ZoneID attached to an outgoing URI, as it has only local significance at the sending host." This requires a transformative rewrite of any URLs going out the wire. That's pretty substantial. Anne, do you recall the bug talking about IP canonicalization (e.g. http://127.0.0.1 vs http://[::127.0.0.1] vs http://012345 and friends?) This is conceptually a similar issue - except it's explicitly required in the context of <zone_id> that the <zone_id> not be emitted. There's also the issue that zone_id precludes/requires the use of APIs that user agents would otherwise prefer to avoid, in order to 'properly' handle the zone_id interpretation. For example, Chromium on some platforms uses a built in DNS resolver, and so our address lookup functions would need to define and support <zone_id>'s and map them to system concepts. In doing so, you could end up with weird situations where a URL works in Firefox but not Chrome, even though both 'hypothetically' supported <zone_id>'s, because FF may use an OS routine and Chrome may use a built-in routine and they diverge. Overall, our internal consensus is that <zone_id>'s are bonkers on many grounds - the technical ambiguity (and RFC 6874 doesn't really resolve the ambiguity as much as it fully owns it and just says #YOLOSWAG) - and supporting them would add a lot of complexity for what is explicitly and admittedly a limited value use case. 122611 3 annevk 2015-08-14 12:04:56 +0000 Thank you Ryan. https://github.com/whatwg/url/commit/ca97ec836d3ff246d5c53f420b0eb2798f2a982c 128599 4 1670 gentle.jack35 2017-05-25 05:22:37 +0000 Created attachment 1670 HTML5 Currently resolved.. 128602 5 mike 2017-05-25 05:49:26 +0000 The content of attachment 1670 has been deleted 1670 2017-05-25 05:22:37 +0000 2017-05-25 05:22:37 +0000 HTML5 header.svg text/plain 0 gentle.jack35