Closed Bug 720331 Opened 9 years ago Closed 7 years ago
.referrer returns punycode instead of non-ASCII (encoded) chars on idn domains
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111222095143 Steps to reproduce: 1. Open http://президент.рф/ 2. Click on the site logo (white text "Президент России" on blue background) 3. Open Scratchpad and execute "alert(document.location.href); alert(document.URL); alert(document.referrer);" Actual results: 3 alerts: "http://президент.рф/", "http://президент.рф/" and "http://xn--d1abbgf6aiiy.xn--p1ai/" Expected results: 3 alerts: "http://президент.рф/", "http://президент.рф/" and "http://президент.рф/"
Additionally Google Chromium does not encode idn in all cases, Opera encodes idn in all cases.
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general
What we currently return from document.referrer is the string we actually sent to the server in the "Referer" header. The spec on this says, amongst other things: Note: In the case of HTTP, the referrer IDL attribute will match the Referer (sic) header that was sent when fetching the current page. but this text is non-normative... I've raised a spec issue to get this sorted out: http://lists.w3.org/Archives/Public/public-html/2012Feb/0046.html
Summary: document.referrer does not encoded on idn domains → document.referrer returns punycode instead of non-ASCII (encoded) chars on idn domains
Boris: Do you got a response for your raised spec issue ? bug 852796 mentions that "This works properly in Chrome since they use decoded URLs everywhere."
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes, in example of bug 852796 which is http://ит-7.рф/test.html it works in IE10, Chrome and Opera: http://browsershots.org/http://xn---7-vlc4b.xn--p1ai/test.html
> Boris: Do you got a response for your raised spec issue ? No. I just resent it to whatwg in hopes that that will work better. > "This works properly in Chrome since they use decoded URLs everywhere." That being punycode everywhere, yes. That seems like a bug in postMessage to me, actually; I've reopened bug 852796 to track this.
This is correct per spec. See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040031.html
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.