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

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
6 years ago
4 years ago

People

(Reporter: Nikolay S. Frantsev, Unassigned)

Tracking

9 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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://президент.рф/"
(Reporter)

Comment 1

6 years ago
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

Comment 2

6 years ago
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
Duplicate of this bug: 852796
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
Flags: needinfo?(bzbarsky)

Comment 5

4 years ago
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

4 years ago
> 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.
Flags: needinfo?(bzbarsky)
Duplicate of this bug: 852796

Comment 8

4 years ago
This is correct per spec.  See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040031.html
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID

Updated

4 years ago
Duplicate of this bug: 743488
You need to log in before you can comment on or make changes to this bug.