Last Comment Bug 720331 - document.referrer returns punycode instead of non-ASCII (encoded) chars on idn domains
: document.referrer returns punycode instead of non-ASCII (encoded) chars on id...
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 9 Branch
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 743488 852796 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-23 02:27 PST by Nikolay S. Frantsev
Modified: 2013-10-02 08:45 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Nikolay S. Frantsev 2012-01-23 02:27:02 PST
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 2012-01-23 02:30:32 PST
Additionally Google Chromium does not encode idn in all cases, Opera encodes idn in all cases.
Comment 2 Boris Zbarsky [:bz] (TPAC) 2012-02-03 22:50:22 PST
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 3 Matthias Versen [:Matti] 2013-03-20 04:58:30 PDT
*** Bug 852796 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Versen [:Matti] 2013-03-20 05:00:56 PDT
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 2013-03-20 05:39:13 PDT
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 [:bz] (TPAC) 2013-03-21 09:06:42 PDT
> 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 7 Burak Yiğit Kaya [:BYK] 2013-04-03 14:50:27 PDT
*** Bug 852796 has been marked as a duplicate of this bug. ***
Comment 8 Boris Zbarsky [:bz] (TPAC) 2013-07-12 11:34:50 PDT
This is correct per spec.  See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040031.html
Comment 9 Boris Zbarsky [:bz] (TPAC) 2013-10-02 08:45:07 PDT
*** Bug 743488 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.