- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 04 Feb 2012 01:50:02 -0500
- To: public-html@w3.org
Oh, and see https://bugzilla.mozilla.org/show_bug.cgi?id=720331 for the bug report that prompted this thread. -Boris On 2/4/12 1:45 AM, Boris Zbarsky wrote: > 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:50:30 UTC