720331 - document.referrer returns punycode instead of non-ASCII (encoded) chars on idn domains

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Nikolay S. Frantsev]

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://президент.рф/"

Comment 1

[Nikolay S. Frantsev]

Additionally Google Chromium does not encode idn in all cases, Opera encodes idn in all cases.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Matthias Versen [:Matti]]

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."

Comment 5

[Loic]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is correct per spec.  See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040031.html