Closed Bug 234736 Opened 21 years ago Closed 21 years ago

javascript:window.location reassignment creates bogus referrer

Categories

(Firefox :: General, defect)

x86
Windows 98
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 122668

People

(Reporter: persist1, Assigned: bugzilla)

Details

User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 When reassigning window.location via the Location bar or a bookmarklet, the page in the browser window at the time the reassignment occurred is shown in the access log as the referrer. Discovery of the issue was as follows: I have a bookmarklet that allows me to provide a timestamp for a single archived entry in my blog to the end of requesting that single entry. I used it while a friend's site was loaded into that tab, and the friend's site was shown as the referrer. I was then able to reproduce the problem simply by putting JavaScript in the Location bar as described in the Actual Results. Reproducible: Always Steps to Reproduce: 1. Create a bookmarklet that reassigns window.location, or reassign it manually from the Location bar. 2. Look up the visit in your serverlogs. Actual Results: In one instance, when typing "javascript:window.location = 'http://www.io.com/persist1/log.php'" into the Location bar while http://badpoetry.net/katie/ was already loaded into the browser window: 4.13.31.137 - - [17/Feb/2004:23:25:27 -0600] "GET /persist1/log.php HTTP/1.1" 200 5182 "http://badpoetry.net/katie/" "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8" I run TabBrowser Extensions, and closed all of my tabs before reproducing the problem again. Expected Results: ...Left empty the referrer field of the access log entry. AFAIK, page requests generated via JavaScript window.location reassignment or window object method invocation never create referrers; at least this has been the S.O.P. since 1996 without regard to who publishes the software... While I can see the benefit to providing a referrer in the event that INLINE CODE generated the page request (thus preventing anonymous referrals), doing the same in the event that the code was stored locally outside of the cache (e.g. in chrome or a bookmarklet) could be understood to be an egregious (if inadvertent) violation of user privacy.
*** This bug has been marked as a duplicate of 122668 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.