On Fri, Jul 12, 2013 at 11:35 AM, Boris Zbarsky <[email protected]> wrote: > On 7/12/13 2:15 PM, Ian Hickson wrote: >> What's not useful about the way it's defined? It's set to a specific >> string. > > I couldn't find where it was normatively set to anything. > >>> In cases when the hostname is non-ASCII, the Referer header will have it >>> encoded in punycode. >> >> Is that defined anywhere? > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which > defines it syntactically as a URI, which means that if you have an IRI you > have to convert it to an IRI before putting it in there. > >> That's correct per spec (assuming the punycoding is required anywhere). >> The latter two are set separately than document.referrer: >> >> http://whatwg.org/html/#set-the-document's-address > > The thing is, people are comparing origins from postMessage to origins from > document.referrer. See > <https://bugzilla.mozilla.org/show_bug.cgi?id=852796#c6>. Also see > <https://bugzilla.mozilla.org/show_bug.cgi?id=720331>. > > Also, as a note, nothing above makes it particularly clear that "the URL > that was originally to be fetched" is not already punycode... Ah, well. > >> If other browsers don't match this, file bugs on them. :-) > > <shrug>. It probably won't do much good, but: > > http://code.google.com/p/chromium/issues/detail?id=259920&thanks=259920&ts=1373653828
I don't think we're likely to change this behavior. We always use punycode for URLs except in the location bar. Why not change Firefox to use punycode in window.location? Adam
