User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 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: http://www.themercury.news.com.au/favicon.ico 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:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 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

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: http://www.aol.com/favicon.ico 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 ----------------------------------------------------------

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

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

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

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/7cc0546438c7 send referrer info for favicons and obey the referrer policy when doing so, r=mossop