- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 04 Feb 2012 01:45:51 -0500
- 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 there. -Boris
Received on Saturday, 4 February 2012 06:46:19 UTC