6 ms·

> In theory, there is guidance for how to properly handle IPv6 zones in user interfaces in RFC 9884, but there's no such guidance for URLs. RFC 6874: Represent

by neild 3mo ago

> In theory, there is guidance for how to properly handle IPv6 zones in user interfaces in RFC 9884, but there's no such guidance for URLs. RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (https://www.rfc-editor.org/rfc/rfc6874.html https://www.rfc-editor.org/rfc/rfc6874.html) Which says that, yes, you need to %-encode the %, so a URL containing a host of fe80::4%eth0 becomes http://[fe80::4%25eth0]/. Yes, that's ugly. Sorry. > TL;DR: computers were a mistake. I agree entirely. (For what it's worth, I am a maintainer of Go's net/url package, and I believe net/url correctly handles zone ids in URLs. It's always possible there's something wrong I'm not aware of. Please let me know if there is!)

agwa 3mo ago
That RFC is obsoleted by https://datatracker.ietf.org/doc/html/rfc9844 https://datatracker.ietf.org/doc/html/rfc9844 which removes all guidance around URIs: > This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.
- neild 3mo ago
  Fair enough, but that leaves us with no way to represent zone IDs in URLs at all. Neither http://[fe80::4%eth0]/ nor http://[fe80::4%25eth0]/ is valid under RFC 3986. Given that net/url has supported RFC 6874 since before RFC 9844 came along, our choices are: * Keep supporting the RFC 6874 syntax. * Drop support for it, require strict RFC 3986, have no support for zone IDs in URLs at all. Breaks existing users, utterly infeasible. * Stop supporting RFC 6875 and start supporting an unescaped % as the zone ID separator, which conforms to no standard I know of. Also breaks existing users, infeasible. * Some sort of hybrid where we try to support both %25 and % as a separator? Ugh. Of these, keeping the existing support as-is until or unless a new standard comes along seems like the best option.
  - agwa 3mo ago
    Yeah, I agree. No criticism of Go's behavior is intended; just pointing out that the RFC is technically dead.
deleted 3mo ago
[deleted]
xena 3mo ago
I have published a fix to the post, it should be live within a minute. Thanks! https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebdc9820ac4b3e648 https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebd...
- arcanemachiner 3mo ago
  The sibling comment to yours may be useful: https://news.ycombinator.com/item?id=48405808 https://news.ycombinator.com/item?id=48405808
  - xena 3mo ago
    i hate computers

by neild 3mo ago

agwa 3mo ago

That RFC is obsoleted by https://datatracker.ietf.org/doc/html/rfc9844 https://datatracker.ietf.org/doc/html/rfc9844 which removes all guidance around URIs: > This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.

neild 3mo ago
Fair enough, but that leaves us with no way to represent zone IDs in URLs at all. Neither http://[fe80::4%eth0]/ nor http://[fe80::4%25eth0]/ is valid under RFC 3986. Given that net/url has supported RFC 6874 since before RFC 9844 came along, our choices are: * Keep supporting the RFC 6874 syntax. * Drop support for it, require strict RFC 3986, have no support for zone IDs in URLs at all. Breaks existing users, utterly infeasible. * Stop supporting RFC 6875 and start supporting an unescaped % as the zone ID separator, which conforms to no standard I know of. Also breaks existing users, infeasible. * Some sort of hybrid where we try to support both %25 and % as a separator? Ugh. Of these, keeping the existing support as-is until or unless a new standard comes along seems like the best option.
- agwa 3mo ago
  Yeah, I agree. No criticism of Go's behavior is intended; just pointing out that the RFC is technically dead.

deleted 3mo ago

[deleted]

xena 3mo ago

I have published a fix to the post, it should be live within a minute. Thanks! https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebdc9820ac4b3e648 https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebd...

arcanemachiner 3mo ago
The sibling comment to yours may be useful: https://news.ycombinator.com/item?id=48405808 https://news.ycombinator.com/item?id=48405808
- xena 3mo ago
  i hate computers