W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 04 Feb 2012 01:45:51 -0500
Message-ID: <4F2CD41F.8080100@mit.edu>
To: HTML WG <public-html@w3.org>
The spec for document.referrer says:

   The referrer attribute must return either the current address of the
   active document of the source browsing context at the time the
   navigation was started (that is, the page which navigated the
   browsing context to the current document), with any <fragment>
   component removed; or the empty string if there is no such
   originating page, or if the UA has been configured not to report
   referrers in this case, or if the navigation was initiated for a
   hyperlink with a noreferrer keyword.

however it then follows with a non-normative note:

   Note: In the case of HTTP, the referrer IDL attribute will match the
   Referer (sic) header that was sent when fetching the current page.

In cases when the hostname is non-ASCII, the Referer header will have it 
encoded in punycode.  The question is what should happen for 
document.referrer.  Right now, I see the following behavior:

1)  Gecko shows exactly the string we put on the wire in 
document.referrer (punycode and all).  document.URL and 
document.location.href show the non-ASCII chars in some cases.

2)  WebKit (or at least Chrome) seems to return punycode for all three 
of these.

3)  Opera seems to return non-ASCII chars for all three of these, at 
least in some cases.

No idea what IE does.

The question is whether it's more important for document.referrer to 
match the HTTP header (so the note will actually be true) or 
location.href and .URL...  Well, and the other question is what .URL and 
location.href should return, since clearly we don't exactly have interop 

Received on Saturday, 4 February 2012 06:46:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:20 UTC