New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 36 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Apr 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

referer-header is not set when opening link in new tab via context menu

Reported by menn...@gmail.com, Sep 9 2008 Back to list

Issue description

Product Version      : 0.2.149.29 (1798)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. rightclick a link and choose 'open in new tab' or middle-click the link
2. The http-request on the new tab doesn't send the referer header to the 
server.


What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if 
possible.
 
 

Comment 1 by menn...@gmail.com, Sep 9 2008

Sorry, forgot to provide 'expected result' and 'what happens instead':

What is the expected result?
Chrome should send the referer header also when opening the link in a new tab.

What happens instead?
The header is not send :)
Labels: -area-unknown Area-Misc

Comment 3 by jon@chromium.org, Nov 11 2008

Taking these to triage.

Comment 4 by jon@chromium.org, Nov 14 2008

Labels: -Area-Misc Area-WebKit NewHTTP Mstone-1.1
Status: Available
We need an automated test case for this.

Comment 5 by jon@chromium.org, Nov 14 2008

 Issue 2482  has been merged into this issue.

Comment 6 by *mdu@chromium.org, Nov 21 2008

Does this mean the "Referer" variable in HTTP Header is missing? If so, I think we 
need a server side script to test this.

Comment 7 by *mdu@chromium.org, Nov 24 2008

Labels: HasReduction
It works fine in IE7 and Firefox304, but has same issue in Safari32.

To make the reduction work, an application server is needed to interpret jsp file and 
the href property of A tag in test-standard.html is also needed to change 
accordingly.

Will try to set up an internally accessible server later.
test-standard.html
465 bytes Download
http-header-info.jsp
659 bytes View Download

Comment 8 by jon@chromium.org, Dec 4 2008

Is the test in place?
Here is the test: http://go/1935-reduction

Comment 10 by jon@chromium.org, Dec 10 2008

Ready for engineering.

Comment 11 by igi...@gmail.com, Jan 9 2009

Referrer, not Referer please.
Labels: Mstone-2.0

Comment 13 by jon@chromium.org, Jan 14 2009

Status: Assigned
See the spec at http://tools.ietf.org/html/rfc2616#section-14.36 for the correct 
(mis)spelling.  :)

I wonder if Eric's work related to https://bugs.webkit.org/show_bug.cgi?id=20806 will 
change/fix this.  I am assigning this to him for comment.

Eric, if you have not fixed this then we need to upstream this bug to WebKit as it 
also happens on Safari.
This sounds similar to another bug that fixed:
http://code.google.com/p/chromium/issues/detail?id=3224
(ctrl-click / shift clicking links didn't send referrer):

jon:
Unfortunately 20806 is in limbo right now, still trying to get someone to review it...

ananta:
I am unable to load your reduction at http://go/1935-reduction

Labels: -Area-WebKit -NewHTTP
Summary: referer-header is not set when openening link in new tab via context menu (was: NULL)
Ok, so the specific problem is opening a new tab/window via the context menu.

When you ctrl-click or shift-click the link, the navigation is initiated via the renderer, and as of http://code.google.com/p/chromium/issues/detail?id=3224 we set the referrer in the navigation.

HOWEVER, when you do the same action by having opened the context menu, the navigation is instead initiated by the browser, and the referrer at 
this point is not known:

The problem code is in render_view_context_menu_controller.cc:

    case IDS_CONTENT_CONTEXT_OPENLINKNEWTAB:
      OpenURL(params_.link_url, NEW_BACKGROUND_TAB, PageTransition::LINK);
      break;

    case IDS_CONTENT_CONTEXT_OPENLINKNEWWINDOW:
      OpenURL(params_.link_url, NEW_WINDOW, PageTransition::LINK);
      break;


Really OpenURL should be being passed a referrer for the link (otherwise it will default to none).

The right fix is probably to extract the referrer from the renderer, and include it in the params.
Note that the simple fix of using the current tab's URL as referrer is insufficient, since the link could have come from a subframe.


Assigning back to Jon for prioritization.



(The bug is in the chromium ui browser code, so removed the webkit and newhttp labels).


Comment 16 by jon@chromium.org, Jan 14 2009

Labels: Area-BrowserUI
Status: Available
Summary: referer-header is not set when opening link in new tab via context menu (was: NULL)
Loss of Referer is a big enough deal that I think we do need to fix it in 2.0.  As 
Eric has identified the problem as being in the browser I am setting the Area as 
Browser UI. 
Labels: -Mstone-2.0 Mstone-X
 Issue 9755  has been merged into this issue.

Comment 19 by Deleted ...@, Aug 14 2009

What's the status of this bug?
Noticed that chrome also does send the referrer information after a meta refresh. This 
behavior is not expected compared to other browsers. This gives everyone the 
opportunity to send referrer information regardless of user actions. Affiliates could 
use this method to redirect an adwords campaign directly to the affiliate advertiser. 
The advertiser will not be able to detect the possible scam because the referrer 
information is invalid. IE or FF consider that it should be empty.

Comment 22 by Deleted ...@, Nov 22 2009

Comment 23 by Deleted ...@, Dec 8 2009

'Google Chrome' doesn't send Referrer while opening new tab.

Is this bug fixed? 
Couldn't this bug get a higher priority? Especially in the context of the rising 
adoptions of Google's First Click Free. It's pretty annoying to only get full content 
if the window was opened in same tab.

Comment 25 by oritm@chromium.org, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label

Comment 26 Deleted

Seconding comment 21: sending refer(r)er on META REFRESH is unexpected and - in my
opinion - incorrect.

Comment 28 by Deleted ...@, Jan 30 2010

Comment 21 is very important!
I have tested with:
In html:
<meta http-equiv="refresh" content="0;url=http://example.com"
This sends a HTTP_REFERER but must be blank.
in PHP:
header('Refresh: 0; url='http://example.com';
This sends a HTTP_REFERER but must be blank.
In html/javascript:
<body onload="location.href='http://example.com">
This sends a HTTP_REFERER but must be blank.
I think this is very important issue en must be soon resolved.
FF and IE are oke.
Labels: Area-UI
Labels: -Area-UI-Features

Comment 31 by matias@google.com, Feb 24 2010

This also affects pages and extensions that use the document.referrer property.
The document.referrer property for clicks that open in a new tab is populated only 
after a ctrl-click, but not after a context-menu Open in New Tab.

I heartily agree with prioritizing this higher.

Comment 32 by Deleted ...@, Mar 3 2010

This is not a bug, it is a nice to have feature. There should also be a way to turn 
globally turn off referer headers, since clients do not actually have to supply a 
referer according to the RFC.

Comment 33 by Deleted ...@, Mar 4 2010

@beefsprocket You're dead wrong. I'm all for a way to turn off HTTP_REFERER headers, 
like in PrefBar, but generally sending those is expected behavior, IOW a quasi 
standard, therefore a *must have*. 
IDK about preferred stats tools for analytics (which reading the linked site seems to 
be the only reason to want the referer string). Expecting a browser to provide website 
operators with nice to have info as a quasi-standard borders on just plain 
entitlement. This is not a bug, it is a feature request. It shouldn't detract from 
more important bug fixing work.

Comment 35 by Deleted ...@, Mar 5 2010

@jamonation It's not only about analytics, and you obviously didn't read the article. 

Not sending the HTTP_REFERER breaks functionality. 

The current behavior totally irritates users. 

For example many sites protect the content in their members area by checking the 
referrer (I can think of better methods to implement hotlink protection, but that's 
reality). If the referrer is empty or points to another domain, then images, vids and 
whatnot aren't delivered to the user agent, often the request bounces to the login 
script. 

Now explain to a user why their browser behaves differently depending on the method 
used to open a link (e.g. left click vs. "open in new tab/window" from the context 
menu). That's a support nightmare, and pisses off both users and webmasters/site 
owners.

If Chrome would generally leave the HTTP_REFERER blank, then users who've paid for 
the content wouldn't use Chrome, but at least the behavior would be consistent. Site 
owners would just post a warning like "Chrome can't handle our site, please download 
IE6 here" or so. 

Not that I'd like to see the Web plastered with crap like that, but it would be the 
right thing to do if your "sending a referrer is nice to have, hence not important" 
take on this issue would be valid. Of course it's just uninformed, or based on 
ignorance, I don't know and honestly couldn't care less. Every experienced webmaster 
will tell you that you're dead wrong, provided you'd bother to ask before you speak 
out.

Comment 36 by Deleted ...@, Mar 6 2010

I disagree on the above suggested handling of the HTTP_REFERER after meta refreshs.

Un-delayed (0 seconds) as well as short-delayed (from my tests like 5 seconds or 
less) meta refreshs are handled like 301 redirects across the boards. For example all 
major search engines interpret such client sided redirects as a permanent redirect. 
More info:
http://sebastians-pamphlets.com/google-and-yahoo-treat-undelayed-meta-refresh-as-301-
redirect/
The same goes for JavaScript redirects by the way. All immediate client sided 
redirects are handled more or less equally to server sided redirects.

Regardless whether search engines handle immediate meta refreshs as 301 or 302, or 
even 307, the user is obviously not supposed to consume the current page, but the 
redirect's destination. The keyword is "redirect".

From a users's perspective, the technology used to redirect an HTTP request is not 
transparent. In other words, a user doesn't care whether the redirect is performed as 
a meta refresh or via HTTP response header. Webmasters on free hosts, blogging 
services etc often can't do server sided redirects, so they have to use meta 
refreshs.

Hence meta refreshs and alike, at least those that take the user to another resource 
within a very short period of time, should be handled as real redirects, that means 
the browser should send the URI where the user clicked a link as HTTP_REFERER.

Comment 37 by Deleted ...@, Mar 6 2010

Sorry for breaking the link. Here you go:
http://bit.ly/clzILH

Comment 38 by Deleted ...@, Apr 16 2010

I middle click to open a new tab.  Then right click on the same link and copy the 
link.  Then go to the new tab and paste the link into the address field.  

Middle click works fine in Foxfire, opening the correct link.

My vote is that this needs to be fixed.  This has been going on for awhile.  Why 
hasn't it been fixed?  And would it come out as an update to IE 8?

And how can we complain to IE 8 developers to get them working on a fix?

Comment 39 by kenorb@gmail.com, Sep 29 2010

Yes, middle click does work, option from context menu not.

Comment 40 by Deleted ...@, Nov 30 2010

'Google Chrome' doesn't send Referrer while opening new tab.

Is this bug fixed? 

Comment 41 by jfi...@gmail.com, Dec 17 2010

Was going to report this; glad to see it's already on the table. If a browser is going to pass referer info at all should be passed regardless of whether you open in the same tab, a new tab, or a new window. And yes, many webmasters use referer info for functionality as well as tracking.

FF and IE get it right. Safari drops the ball on this as well.
I've just spent quite some time trying to track down how a user appeared to have hit an obscure URL directly (ie with no referer - even though other pages they accessed did have referer info), before eventually finding this issue.

This bug has been open for a while now - when can we expect a fix?
I am currently considering engineering work arounds or just blocking Chrome & Chromium based browsers over this issue for a project I am working on.

The support cost is going to be too high.

It is also convenient because I won't have to worry about WebM support in HTML5.

I also agree with the meta refresh stuff Sebastian mentioned - consistant behavior is essential especially for affiliate marketing.

In early stages of discussion, the issue was being "triaged" - it seems for the last 2 years this has been swept under the table.

Comment 44 by Deleted ...@, Feb 1 2011

Why is this bug not considered a security issue?

One solid way of preventing every CSRF (cross-site request forgery) is to block anything with the wrong 'Referer' field. If Webkit makes a mockery of the Referer field, how on Earth are web developers supposed to secure their apps without going insane?

Regards,
Frustrated Web Developer

Comment 45 by Deleted ...@, Feb 1 2011

Happy to see that this still isn't resolved. If it is such an issue, and with all the purported web-development talent (and crying and moaning) around here, I'd expect someone would have submitted a working patch by now

Since they haven't, this must not be an issue after all.
hey, i have patched up the problem. i've made the referer to be sent on right click and open in new tab/ open in new window. should i get this bug assigned to me before i submit the patch?
Status: Started
you can't "own" a bug unless you have a chromium account, so commenting here should be good enough. I'll mark as started: http://codereview.chromium.org/6681030/
Cc: ananta@chromium.org
BTW I've been reviewing a patch to do this: http://codereview.chromium.org/6681030/
Project Member

Comment 50 by bugdroid1@chromium.org, Apr 20 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=82323

------------------------------------------------------------------------
r82323 | brettw@chromium.org | Wed Apr 20 10:27:17 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/render_view.cc?r1=82323&r2=82322&pathrev=82323
 M http://src.chromium.org/viewvc/chrome/trunk/src/AUTHORS?r1=82323&r2=82322&pathrev=82323
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/render_view_context_menu.cc?r1=82323&r2=82322&pathrev=82323
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/render_view_context_menu.h?r1=82323&r2=82322&pathrev=82323

Send the 'page_url' parameter of the page (on which the right click was made to
open the context menu) as the 'referer' field of the http header field. This
change is done for cases OPENLINKNEWTAB, OPENLINKNEWWINDOW, and NOT for
OPENLINKOFFTHERECORD (Incognito).  Also Https to Https transition must NOT send
the referrer and this is checked in the 'OpenURL' method.  Call to the
ShouldHideReferrer method is done at render_view.cc

Author Ramkumar Gokarnesan - ramgo@yahoo-inc.com
BUG= 1935 
TEST=Try right click on a URL and click 'open link in new tab' or 'open link in new window' and see the referer information being sent as a part of the http header field. verify with wireshark / VS debugger.
Original review http://codereview.chromium.org/6681030/
------------------------------------------------------------------------
Status: Fixed
Should be fixed in r82323.

Note to people with this starred: this should get to stable in Chrome 12.
Sorry, I mean Chrome 13.

Comment 53 by Deleted ...@, Jun 6 2011

do we have a date when a fix will be in place?
Project Member

Comment 54 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 55 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-UI Cr-UI

Sign in to add a comment