You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RFC 6761 does claim "Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address." which would imply that it should be reasonable for "localhost" to be "potentially trustworthy".
Having 127/8 and ::1 but not localhost in the "potentially trustworthy" set seems to have the risk of encouraging hard-coding of breaking the name/IP abstraction boundary and hard-coding client-side addresses in to URLs on the server without knowing client capabilities. It will be unfortunate if clients need to keep around their IPv4 stack or manually rewrite 127.0.0.1 to ::1 just for these sorts of use-cases. Both rfc1900 and rfc2616 explicitly discourage using addresses. ("The use of IP addresses
in URLs SHOULD be avoided whenever possible" in rfc2616 and rfc1900 is harsher.)
It seems like a better result would be to allow "localhost" (and encourage it over hard-coding an address) as long as it resolves to either 127.0.0.0/8 or ::1 ? Security considerations should of course mention that some implementations are buggy and clients should either verify the resolution to a loopback address (or perhaps should consider hard-coding the translation?)