User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040911 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040911 Firefox/0.10 Recently Firefox was changed so that by default, it will search for /favicon.ico (in the root web path) on every page request, where a server doesn't have a /favicon.ico file. However, under this new behaviour the number of HTTP transactions is effectively doubled. For instance, every time I go to a new site Firefox will request the current URL as well as favicon.ico, getting a 404 error for favicon.ico. Unfortunately, it appears that this behaviour was implemented for compatibility with sites designed for Microsoft Internet Explorer. Firefox's current implementation of it is over-agressive and ultimately worse than IE's. Firefox sends a request for /favicon.ico file on every page load, rather than just once when the page is bookmarked. In my opinion, if we are going to add features in order to be compatible with sites designed for Microsoft Internet Explorer, then at the very least these features should not be excessively resource-intensive. Reproducible: Always Steps to Reproduce: 1. Go to a website which has no shortcut icons or favicons. Actual Results: Firefox searches for /favicon.ico on every page request. Expected Results: Firefox doesn't search for /favicon.ico on every page request.

I've noticed the same behaviour in my apache logs. You would expect Firefox to remember whether a site has a favicon or not for the current session.

I've got the same warnings in the Websphere logs. I would expect Firefox not to do that kind of TOTALLY WRONG assumption. To have a favicon you MUST have the following line in your HTML code: <LINK rel="Shortcut Icon" href="/images/myicon.ico"> The following log entry is displayed in WebSphere: [9/28/04 11:18:11:135 CEST] 6db66db6 OSEListenerDi E PLGN0021E: Servlet Request Processor Exception: Virtual Host/WebGroup Not Found : The web group /favicon.ico has not been defined

Have just noticed this as well. I thought Mozilla put an entry in a cache to record 404 favicons to stop them being continually 'fetched'. There is also a request every time the tab is selected which I have filed as bug 262626. I think this should be higher than minor - we could upset a lot of webmasters

see also bug 262262

This could be a dup. I would be surprised if there is an engineered solution to this at all, and to create one perhaps someone needs to draw up a specification or standard for favicons. I would be surprised if the one fetch per session satisfies everyone because it makes life difficult for a webmaster checking the favicons on a site. Perhaps the 404s could be cached for five minutes; I think that squid does something like this.

I would expect the check for favorite.ico to honor browser.cache.check_doc_frequency (which is set to 3 for me)

confirmed on "Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1" my web server log is filling rapidly with these now.

My web error log has become unreadable thanks to Firefox 0.10.1 spam. This is a bug in itself, and I believe it is not an Apache bug. As a webmaster, I'm starting to hope that my users won't switch to Firefox too quickly... As a side note, I was horrified when I first learned that IE was doing a query for a file that is not even referenced, and with a proprietary format on top of that. I can't believe an open-source browser can do worse.

*** Bug 267323 has been marked as a duplicate of this bug. ***

Please REMOVE THE CODE that fetch the favicon.ico. As I explained before, Firefox is TOTALLY WRONG in fetching this image. I'm fed up with this bug that is annoying everyone. Read and learn this : http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp I hope it helps implementing this non standard thing.

Comment 10 is at least a near dup of different bug - icons referenced by LINK REL should take priority. I am not sure that end users would agree that no LINK REL implies no FAVICON; and many people would rather have server wide icons than none at all. Even if there is no consensus on a complete solution for the various issues, surely there is a lot in Comment 8 that a free world application should not repetitively fetch a non-referenced URL - I cannot believe that a Standard would ever be anything like that, or that this would find favour on its own merits.

Can we get rid of this error by just creating a dummy favicon.ico in the document root?

Yes and No. 1. It is not a "we" thing. The file must be provided by a webmaster, and he or she may not have access to the htdocs root of the server. 2. Many webmasters do not want to use this file and resent being pestered for it. 3. There appears to be no standard for favicons, so there is no "right thing" to do. In short, comments 1 8 and 10 apply, and in the absence of a good reason to the contrary, the repetitive fetching of /favicon.ico ought to be either throttled (my preference given that many end user like favicons) or turned off.

Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 I get a daily report from my server logs about 404 errors to help catch site problems, but the report is now useless due to FireFox "favicon.ico" spam. My pages already have a favorites icon - why does FF need to spam me with extraneous HTTP hits? This should be higher than "minor"

I agree that this is an annoying feature of Firefox. There is no justification for it, IMHO. What's more, according to a status page (http://www.mozilla.org/status/2003-01-01.html) it was disabled back in 2002. Clearly, something has gone awry here. It is true to say that /favicon.ico is a de-facto 'standard', apparently unwritten. It does not follow that Firefox should implement it, because there /is/ a defined de-jure standard for doing this using the <link> tag. Firefox should implement the de-jure standard only IMO. I disagree with Comment 11.

(In reply to comment #15) > [ snip ] > > Firefox should implement the de-jure standard only IMO. I disagree > with Comment 11. In this context I agree that "Firefox should implement the de-jure standard only" (I am not sanguine, though, that this would be unopposed). I am perfectly happy to withdraw any part or all of comment 11, or re-cast it into an acceptable form, particularly if this would speed resolution of this bug

The browser.chrome.favicons stop this behaviour...It must maybe be set to false by default...

In a site with some 270 .html files, I use five different icons (depending on the topic of the page). For each such page, I setup a LINK element for its icon. If I have a page without such an element, I don't expect any icon (unless the server forces one). I use these icons to identify my pages and myself. NONE of them are named "favicon.ico". As a user who surfs the Web, I'm not at all perturbed if a page has no icon. The "green bookmark" default provided by Mozilla is sufficient. Therefore, I must agree with comment #10 and disagree with comment #11. Frankly, IE did it wrong by looking for favicon.ico. Lacking a default icon from the server, the only icons that should be displayed are those explicitly requested by the Web pages or automatically provided from the internal working of the browser. Unrequested icons should not be fetched. I'm not even sure a server should throw up a default icon. When Netscape servers first started doing this, it was very confusing. I thought the owners of the affected Web sites were somehow connected to Time-Warner (owner of AOL, which owns Netscape). I later discovered this was merely a way for Netscape to advertise its servers. Thus, from the standpoint of both a Webmaster and a user, I think this needs to be fixed by removing the "feature".

Yes, I've got this problem too. I've currently put up a favicon.ico of about 3MB on my server :) I don't know how this got in, but I find it rediculous that this got in the final Firefox release. Why would anyone do such a weird thing? I don't even know what this file would be usefull for.

I have this problem too. I agree with all the comments above (except Comment #11). I hope the dev team fixes this soon. The severity really should be "Critical".

not really sure where this should go, but reassigning in the hope that it might get someone to look at it.

*** Bug 277922 has been marked as a duplicate of this bug. ***

We had lengthy buig discussions when this got implemented for Mozilla [SeaMonkey] once, and decided to have default-off pref for that, as it had been decided we don't want to cause excess traffic on web servers (you could even call that a form of spamming). <rant>Of course, once again, Firefox implements malicious "features" that were already discussed to death of SeaMonkey, just because Firefox devs are stupid enough to think they have to re-invent every wheel that has been thoughtfully thrown away in the develompent of a decent broswer</rant> To be serious again: Firefox 1.0 could very well be considered malware by people who hate their logs being really spammed by those ill-featured requests for a non-standard file (which is even in a non-standard file format, BTW). It's good to request icons that are referenced by <link rel=""> and they look quite nice as well, but we should never request files that aren't referenced anywhere. If we really have to (I doubt that), we should at least cache the information that it's 404.

Lost in the noise seems to be this fact: Internet Explorer _only_ requests favicon.ico when you add a page to your Favorites. That's why it's called a "favicon". Thus, as I see it, this is not a matter of Firefox being too aggressive, not caching 404 responses, etc. -- it simply shouldn't request favicon.ico _at all_ until you bookmark a page.

Can someone (who can say with some authority) clarify what the proposed fix for this bug is? When I voted for it, I assumed that the fix was to: 1) make no requests if there is an icon in a link tag 2) cache any 404s so the icon isn't repeatedly requested If, as many commenters think, the solution is not to request this file at all, I will remove my vote.

Right now, we don't hammer for favicon.ico if there's one referenced by the appropriate <link /> tag, so that's not an issue. Caching 404 in some way seems appropriate. While we're at it, in-memory cache by hostname for favicions found via the hammering system seems appropriate as well. Disabling favicons by default is not going to happen unless there's no other choice. That's a sledgehammer approach, and one that ignores the usability benefits of site icons for tabbed browsing.

(In reply to comment #26) > Disabling favicons by default is not going to happen unless there's no other > choice. That's a sledgehammer approach, and one that ignores the usability > benefits of site icons for tabbed browsing. I'd cosider requesting "favorites" (a.k.a. bookmarks) icons with every pageload to be a "sledgehammer approach". Bot well, it's just Firefox, which is used to the sledgehammer approach anyways - see it's development process.

for the benefit of Michael Newton - Mike Connor is a Firefox developer and can therefore can speak with some authority, while Robert Kaiser's suggestion of turning this off altogether should be a different bug (and rants about Firefox's development process in general shouldn't even be in bugzilla).

(In reply to comment #28) > for the benefit of Michael Newton - Mike Connor is a Firefox developer and can > therefore can speak with some authority, while Robert Kaiser's suggestion of > turning this off altogether should be a different bug (and rants about Firefox's > development process in general shouldn't even be in bugzilla). You're right, of course. And if I'd care personally for Firefox enough, I'd file a bug for that and look for the previous discussion of that. But I don't really care enough about Firefox personally (opposed to my interest in FF L10n as MLP leader, BTW, but it's my problem to deal with that "split personality" thing). Adhering to a non-standard made by someone without standard autority for some other purpose than what we are doing is not the nice way though, and I'm with mconnor that if we want to keep that so-called feature, we should at least try to reduce the amount of unwanted web traffic we cause throught that cr... er... function.

(In reply to comment #29) I believe the right fix for this bug would be to not query a file like "favicon.ico" that is not referenced. But I admit the description is not clear enough to lead directly to this fix. Since Firefox is not my main browser, I would not care about it if it was a good netizen. But this browser is getting really annoying. So, I filed bug 279891 to suggest a better behavior. Please report your votes to bug 279891 if you think the correct fix for this bug is to not query for favicon.ico when it is not referenced.

Arguably, there's a use for querying for favicon.ico, but the lack of decent caching for this makes it a feature that does quite a bit of infrastructure harm in the process of being a tab browsing usability gain. Though, why would browser vendors care about the resources of the internet's servers? ;-) Either way, the chances of getting favicon.ico support for tabs disabled is none. The best that can be hoped for is better (i.e. responsible) caching of the image and if it was a 404 (or other 400 series error). One request per host per client is alot better than the current situation where its repeatedly requested. Each one of those bogus 404 requests takes up a connection to, for example, an Apache worker that could be serving data. (and since a server only his a finite number of workers.) BTW, even addons.update.mozilla.org is dropping support for favicon via <link> in favor of /favicon.ico, see Bug 279004. and Comment #5 of that bug even suggests doing it for mozilla.org itself.

"Each one of those bogus 404 requests takes up a connection to, for example, an Apache worker..." It also takes up one of a limited number of connections from the browser. Even if we don't care about impact on servers, this also has an impact on users, particular those with slower connections. "BTW, even addons.update.mozilla.org is dropping support for favicon via <link> in favor of /favicon.ico" That's up to the UMO folks - if in future they want different icons for different bits, they can add a few more unnecessary subdomains to the hostname. :)

Note: the bug in question was morphed into fixing the link. It makes no sense to kill the <link> tag in this case.

Even though mconnor has WONTFIXED the other bug, I still think what I said in bug 279891 comment #1 would be an idea to think through. What I basically said is add good caching for favicon.ico and don't request it at all in standards mode, only in quirks mode. That way, we would at least not "force" standards-compliant web designers to put up a completely non-standard file. Those who can write up standards compliant pages should know how to insert a <link> tag to get the icon.

Issues: [1] There are 2 bugs here. One is that the request is being repeated ONCE FOR EACH HIT; the other is that it is being repeated TWO TO FOUR TIMES PER HIT. I just downloaded Firefox and went to 3 links at http://www.dnsstuff.com, and there were 6 favicon.ico hits (per a packet sniffer). There should have been a minimum of 0 hits and a maximum of 1. [2] This bug is wreaking havoc for users of my website www.dnsstuff.com . Due to spammers harvesting E-mail addresses, I have to rate limit my users. Because of this bug, the rate limiting system will see 2-4 bogus hits for every one legitimate hit. If the site sees such high usage in a short time period, it blocks the IP. My recommendations: [1] I am considering blocking FireFox users (remember, each bogus favicon.ico hit uses up about 1K of bandwidth), just returning a page explaining the problem. [2] Redirect www.dnsstuff.com/favicon.ico to www.mozilla.org/favicon.ico. The problem with this, though, is that it would end up being a DDoS attack (if every website did it, Mozilla's site would almost certainly be unusable). [3] Get confirmation that this bug is going to be fixed in such a way that the \favicon.ico file is only requested at MOST once per session. -Scott

(In reply to comment #35) > Issues: > > [1] There are 2 bugs here. One is that the request is being repeated ONCE FOR > EACH HIT; the other is that it is being repeated TWO TO FOUR TIMES PER HIT. Not true. I use Live HTTP headers [http://livehttpheaders.mozdev.org/] to inspect the HTTP request/response and there is only 1 request of favicon.ico per page view. Please avoid discussion here. Bugzilla is not a discussion forum.

(In reply to comment #36) I know of what I speak. I've looked at many, many log file entries as a result of this bug. In every case I've seen with Firefox, there have been 2-4 favicon.ico hits for each real hit. This may be due to something unusual about what Firefox is seeing (for example, the 404 wasn't getting a true HTML page back, it was getting plain text), but it definitely was happening. And yes, I have confirmed this with a packet sniffer. Try going to http://backup.dnsstuff.com and going to about 5-10 pages, and you should more favicon.ico hits than the number of pages you go to. In any case, I've redirected /favicon.ico on the main site to www.mozilla.com/favicon.ico, as it won't have the negative effect I was afraid it would (I was assuming all those 39,000 /favicon.ico hits I got yesterday would be directed; fortunately, this bug doesn't cause re-tries if Firefox gets the icon). -Scott

*** Bug 281265 has been marked as a duplicate of this bug. ***

This bug does harm beyond needlessly requesting the favicon.ico file: there are sites where `/', and thus `/favicon.ico', are protected by HTTP AUTH (.htaccess). This means that if a user has access to, say, `internal.company.com/public' but not `internal.company.com/', he will be prompted with a HTTP `Basic' AUTH popup after every single click on the page! As Internet Explorer doesn't show this behaviour, it turns out to be hard to convince the webmasters to prevent it.

I like comment #34. Of course, a link tag in quirks mode should override. Comment #39 also makes a point. If Firefox must get "/favicon.ico" and that triggers an HTTP AUTH, Firefox should do without it rather than confusing the user with an authentication dialog just for the sake of an icon.

I agree that this is very bad form for a user agent that is supposed to be geared towards standards. MSIE perhaps did this in 4.0? 5.0? Either way, I don't recall ever seeing it happen in any of the IE versions I've used over the past years and IE 5.5 and 6.0 never do this aggressive searching. Firefox is almost going backwards in this "design decision". It encourges lazyness from webmasters who just dump favicon.ico in their webroot and magically expect it to work and fills logs with 404s and is generally a huge pain. If people want a favicon on their site, they should specify it using the relevant tags, it should not be the job of the user agent to go probing for it.

This behavior is silly coming from a browser that claims to comply with standards. The favicon.ico support is brain-damaged.

Directly linked to that, even when people use an external direct link to a file (non html), firefox try to get a favicon, which is useless, since this person won't even see a single page on my website.

This bug was opened on 2004-09-20, which is almost a year ago. Is this going to be fixed? Or shall we ban Firefox or mod_rewrite all favicon.ico requests to mozilla.org? Microsoft introduced this standard and if you want to implement it too, you are supposed to follow it, not to mis-implement it. IE only requests favicon.ico if the user adds the site to his Favorites. This allows webmasters to estimate how many people added their site to Favorites. Yo say "The Browser, Reloaded". I say, sloppy, ignorant, and slow development.

not able to reproduce on trunk. minusing unless someone can show it's still a trunk problem.

I'm not seeing this anymore in Firefox 1.06 (Linux). I used to get multiple favicon requests with previous versions, but now it appears to behave in a reasonable fashion. Good job!

(In reply to comment #46) > I'm not seeing this anymore in Firefox 1.06 (Linux). I _do_ see this in Firefox-1.0.6 on Linux Fedora Core 3 on i686, downloaded from http://download.mozilla.org/?product=firefox-1.0.6&os=linux&lang=en-US installed to "$HOME/local/mozilla-1.0.6". Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 I have deleted $HOME/.mozilla for testing so I have clean profile, then went to http://www.obietnicewyborcze.pl/ and I can see 404 entry in Apache's error log for every link I click in menu. However I _do_not_ see this bug in today's nightly build downloaded from http://ftp.scarlet.be/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-1.0+.en-US.linux-i686.tar.gz installed to "$HOME/local/mozilla-1.1". Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050720 Firefox/1.0+ When I go to this page with new profile there only is one error log entry - following link clicks do not generate 404 errors in logs. PS. If you can not reproduce this bug check if you use http proxy - you shouldn't. PS2. It is platform:all bug, not WindowsXP only.

This works for me using Firefox 2005072206 trunk on windows 2000. Would be good to know how it was fixed, but given that I'm the third confirmation that it works, I guess it's safe to mark this WFM. If anyone can reproduce this with a recent trunk (i.e. not 1.0.x) build, they should reopen it.

> If anyone can reproduce this with a > recent trunk (i.e. not 1.0.x) build, they should reopen it. Does this mean that this issue will never be fixed in the 1.0.x versions of Firefox?? I am testing with: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 This is my webserverlog: 84.160.49.118 - - [22/Sep/2005:23:17:47 +0100] "GET /test/srv/input?eingabe=1&tim=141 HTTP/1.1" 200 79 84.160.49.118 - - [22/Sep/2005:23:17:47 +0100] "GET /test/jsps/result.jsp HTTP/1.1" 200 57 84.160.49.118 - - [22/Sep/2005:23:17:47 +0100] "GET /favicon.ico HTTP/1.1" 404 986 84.160.49.118 - - [22/Sep/2005:23:17:47 +0100] "GET /favicon.ico HTTP/1.1" 404 986 84.160.49.118 - - [22/Sep/2005:23:18:05 +0100] "GET /test/srv/input?eingabe=2&tim=156 HTTP/1.1" 200 79 84.160.49.118 - - [22/Sep/2005:23:18:05 +0100] "GET /test/jsps/result.jsp HTTP/1.1" 200 57 84.160.49.118 - - [22/Sep/2005:23:18:05 +0100] "GET /favicon.ico HTTP/1.1" 404 986 84.160.49.118 - - [22/Sep/2005:23:18:05 +0100] "GET /favicon.ico HTTP/1.1" 404 986 84.160.49.118 - - [22/Sep/2005:23:18:11 +0100] "GET /test/jsps/rechts.jsp HTTP/1.1" 200 1510 84.160.49.118 - - [22/Sep/2005:23:18:11 +0100] "GET /favicon.ico HTTP/1.1" 404 986 Despite of the 404 error firefox requests favicon at every request! (not from the beginning but after some time)

"Does this mean that this issue will never be fixed in the 1.0.x versions of Firefox??" It means that it shouldn't be reopened based on the fact that it isn't fixed in 1.0.x - the status of bugs in 1.0.x versions is handled with keywords. However, given that 1.0.x will soon be obsoleted by 1.5, and their policy is only to take important security fixes in 1.0.x versions, it's unlikely to ever be fixed in a 1.0.x release.

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

It's 2015, can we get this fixed now?

I agree! I have LOTS of tabs. It seems that every favicon is loaded, rather than cached, for every tab, even if the tab is not visible. consequently, it takes about 6 minutes for firefox to load, even though only a few dozen of the favicons are visible, and, I doubt that the favicons have changed.