3 ms·
Per RFC3986/7, http://example.com/%60 http://example.com/%60 and http://example.com/a http://example.com/a are equivilant. (Indeed, all major browsers will requ
by gsnedders 13y ago
Per RFC3986/7, http://example.com/%60 http://example.com/%60 and http://example.com/a http://example.com/a are equivilant. (Indeed, all major browsers will request the latter regardless of what is input.) Equally, punycode encoded IRIs and the original IRI are equivilance. There is a whole section on equivilance in both of the RFCs (3967 includes 3986 by reference, so is a superset).
- U2EF1 13y agoBrowser equivalence is another thing entirely. Most browsers will accept http://www。google。com http://www。google。com (because in Japanese '。' is '.'). But if you tried to request that actual resource it doesn't lead anywhere. But yeah HN should just use browser equivalence.
- gsnedders 13y agoBut totally undefined and all browsers do their own thing for what's entered in the address bar — there's more consistency in URLs in content, and that doesn't do stuff like normalising '。' but does do the percent-encoded case (for unreserved characters, as the spec says). Following what the spec says for eqivilance makes sense, at least. Anything drastic is technically treating distinct URLs as equivilant.