favicon doesn't send referrer




Tabbed Browser
12 years ago
2 years ago


(Reporter: Graeme Merrall, Unassigned)


(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/

When requesting a favicon from a page that doesn't explicity contain a reference to favicon, the request doesn't include the referring page. While it's actually the browser and not the page request itself making the request, the action is a result of requesting the page.

Plus it also helps in diagnosing 404's in large sites where some pages are missing the <link> tag.

Reproducible: Always

Steps to Reproduce:
Request a web page without a link and observe HTTP headers
Actual Results:  

GET /favicon.ico HTTP/1.1
Host: www.themercury.news.com.au
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive

HTTP/1.x 404 Not Found
Server: Apache/1.3.33 (Unix)
Content-Type: text/html
Date: Thu, 13 Apr 2006 03:23:29 GMT
Content-Length: 30028
Vary: Accept-Encoding
X-Cache: MISS from XX
Proxy-Connection: keep-alive

Comment 1

12 years ago
I think this was done on purpose (privacy reasons ?), but I can't find back the bug right now. I could be wrong though, don't quote me on that.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081026 SeaMonkey/2.0a2pre - Build ID: 20081026000433

I think I see the same symptoms:


GET /favicon.ico HTTP/1.1
Host: www.aol.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081026 SeaMonkey/2.0a2pre
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en-gb;q=0.9,en;q=0.8,fr;q=0.8,fr-be;q=0.7,fr-lu;q=0.6,fr-ch;q=0.5,fr-fr;q=0.5,fr-mc;q=0.4,fr-ca;q=0.3,eo;q=0.2,nl-be;q=0.2,nl;q=0.1
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: tst=,-dp,1219056534; cobr=; tips=1; dlact=dl1

HTTP/1.x 200 OK
X-RSP: 1
Last-Modified: Thu, 30 Jun 2005 10:06:11 GMT
MIME-Version: 1.0
Date: Sun, 26 Oct 2008 21:49:51 GMT
Server: AOLserver/4.0.10
Content-Type: */*
Content-Length: 2862
Connection: keep-alive
Component: General → Networking: HTTP
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → networking.http
Hardware: PC → All
Version: unspecified → Trunk
Component: Networking: HTTP → General
Product: Core → Firefox


2 years ago
Component: General → Tabbed Browser
Depends on: 1119386
Maybe one reason why no referer is sent when requesting favicon.ico, is that the same favicon.ico will be reused for all pages from the same host (except, of course, any pages having an appropriate <link> element).

Also, Patrick and Gijs: this behaviour also affects SeaMonkey (see comment #2), this might be an indication that it could be in shared code. Not a certainty of course: an alternate possibility would be of a common problem existing in two identical, or almost identical, versions of the same code in forked sources, one for Firefox (in mozilla-central/browser/?) and the other for SeaMonkey (in comm-central/suite/?)

Comment 6

2 years ago
(In reply to Andrew Overholt [:overholt] from comment #5)
> Code is in toolkit (courtesy Boris at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1282878#c3):
> http://searchfox.org/mozilla-central/rev/
> bfcc10319e4e3ce78367fa9bba9316f7eb5248b6/toolkit/components/places/
> FaviconHelpers.cpp#402

Note that this is just one of the formerly-three-and-now-hopefully-just-two places that requests the favicon. The other would be the tabbrowser itself that just sets the src attribute of a XUL image to the favicon URI (to get it to appear in the tab). Yes, this means the favicon will sometimes be requested more than once (the toolkit code will only request it if we don't have a recent copy).

Because XUL <image> elements don't let us set the referrer, in order to fix this we'd need to build some kind of cache where we then give out blob URIs instead (or something like that) to serve both callsites. We kind of need to do this for other reasons anyway, because the toolkit code you linked doesn't run for private browsing mode (because we don't want to store favicons in the places DB for navigations in private browsing mode) and I recently made the third favicon consumer, the windows taskbar preview code, rely on the places favicon code for getting this data, which means that in private browsing mode the icons might now be missing from the windows taskbar previews (if we don't have cached icons for the site you're visiting).

I'll ni myself to remind me to file a bug about this tomorrow. I've recently had cause to look at this stuff in more detail than I would have liked, so if people have questions I'm happy to help answer them.
Flags: needinfo?(gijskruitbosch+bugs)


2 years ago
Depends on: 1288054


2 years ago
Flags: needinfo?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.