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

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