W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 12 Jul 2013 11:40:16 -0700
Message-ID: <CAJE5ia_WTqejajPZVxf=cxTipvPyE=g0FWQfj-kJaj1tK583kw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg <whatwg@lists.whatwg.org>
On Fri, Jul 12, 2013 at 11:35 AM, Boris Zbarsky <bzbarsky@mit.edu> 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
Received on Friday, 12 July 2013 18:41:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC