On Wed, May 4, 2016 at 5:52 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
>
> On Wed, May 4, 2016 at 5:52 PM, Chris Palmer <palmer@google.com> wrote:
>
>> On Wed, May 4, 2016 at 12:03 PM, Emily Stark (Dunn) <estark@google.com>
>> wrote:
>>
>> Why differentiate *.localhost from localhost when RFC 6761 doesn't treat
>>> them differently? (I imagine that the argument is that most resolvers treat
>>> localhost as special even if not *.localhost, but that seems like shaky
>>> grounds on which to call something secure-enough.)
>>>
>>
>> You are right, those are shaky grounds.
>>
>> I'm increasingly inclined to remove localhost (but not 127/8 or ::1) from
>> the set of secure contexts, and to resolve the developer-pain problem with
>> a command line flag or other run-time, expert-user option.
>>
>
> I am also trending in that direction.
>
Having 127/8 and ::1 but not localhost 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.)
How viable is it to allow "localhost" as long as it resolves to either
127.0.0.0/8 or ::1 ?
Erik
Received on Monday, 16 May 2016 20:34:31 UTC