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 :)

(No comment was entered for this change.)

Taking these to triage.

We need an automated test case for this.

 Issue 2482  has been merged into this issue.

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

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

Is the test in place?

Here is the test: http://go/1935-reduction

Ready for engineering.

Referrer, not Referer please.

(No comment was entered for this change.)

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

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).

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. 

(No comment was entered for this change.)

 Issue 9755  has been merged into this issue.

What's the status of this bug?

Bump http://sebastians-pamphlets.com/webkit-please-rescue-the-http_referer/

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.

What is your response to this?
http://sebastians-pamphlets.com/webkit-please-rescue-the-http_referer/

'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.

Area-UI-Features label replaces Area-BrowserUI label

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

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.

(No comment was entered for this change.)

(No comment was entered for this change.)

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.

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.

@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.

@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.

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.

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

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?

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

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

Is this bug fixed? 

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.

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

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?

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/

(No comment was entered for this change.)

BTW I've been reviewing a patch to do this: http://codereview.chromium.org/6681030/

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/
------------------------------------------------------------------------

Should be fixed in r82323.

Note to people with this starred: this should get to stable in Chrome 12.

Sorry, I mean Chrome 13.

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