User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.12 Build Identifier: Frefox can request a "favicon.ico" file on a web server even if this server does not contain any web page referencing this file. This is a non-standard behavior, and can be a real hassle for webmasters. Reproducible: Always Steps to Reproduce: 1. take a look at your web error log (assuming you don't have a favicon.ico file on your server) 2. 3. Actual Results: You notice errors because firefox requested a file that doesn't exist. Expected Results: There should be no error, because a web browser should not request a file that is not referenced. There are many reasons why a file that is not referenced should not be requested. They will not be detailed here, but this bug was filed because of the comments for bug 260500. In particular, a suggested fix for 260500 is to cache the non-existence of the file in order to reduced the error spam, while the suggested fix for *this* bug is to never ever query a file that is not referenced.

Of course it's basically wrong to request that file, but it looks like Firefox developers want to show the icon wherever possible. So, it came to my mind that perhaps there's a behaviour that may satisfy both those people who think that it's a usabilty feature to display those icons for pages, and those who think that non-standard files (like this one) should never be requested when we want to tell people we are very standards-compliant. What about only requesting that file when showing pages in quirks mode? In standards (or almost-standards) mode, we just would refrain to fetch that icon. That would mean we don't spam standard compliant web authors with bogus requests. If they do not want to specify an icon, they shouldn't have to. For quirks, which might still request favicon.ico in my idea, we should definately cache the result of the request on a per-host basis (either the icon or that it's 404) to reduce the overhead we're generating. I think both things would even improve Firefox's speed in fetching web pages.

I think this is a feature, not a bug. Just place a dummy favicon.ico file under the root directory of web server and everything solved. In fact, this is now almost a MUST for web servers to have favicon.ico, as users are so used to have a little icon on the tab and location bar.

(In reply to comment #2) > I think this is a feature, not a bug. > Just place a dummy favicon.ico file under the root directory of web server and > everything solved. In fact, this is now almost a MUST for web servers to have > favicon.ico, as users are so used to have a little icon on the tab and location bar. If it just requested the file _the first time_ a page was loaded on that server, it would have been ok for me that it requests a unreferenced file. But the way it is now is just stupid. I can't see one reason not to cache the availability of this file. Especially when this file is not referenced at all. Why should it continue to "hammer" the server with requests for non-existant,non-referenced file. And forcing webmasters to have to make a dummy file is not the right sollution. I feel the favicon.ico requests bothering as much as spam. Sure, you can filter it out, though easier than spam, but should that really be neccecary?

Welcome to the world of de facto standards. If a small amount of "pain" (And I would suggest that its very small) is necessary for users to get a bigger usability gain, we'll make that choice every time.

If Firefox is so desperate to get a favicon, admins should configure their servers to redirect these requests to http://www.mozilla.org/favicon.ico. Maybe that would stop this madness.

Very small amount, multiplied by millions of clients hitting millions of servers. Might be justifyable if it was 1 hit per host, but multiple repeated? sheesh, who didn't think that through before unleashing it on the web in a mainstream browser? :-)

Seriously rude. for this to happen more than once per server. My personal solution from http://www.mozilla.org/unix/customizing.html is userChrome.css: toolbarbutton.bookmark-item:not(.bookmark-group):not([type="menu"]) > .toolbarbutton-icon {display: none;} menuitem.bookmark-item > .menu-iconic-left {display: none;} .tabbrowser-tabs *|tab:not([image]) .tab-icon {display: none;}

See Bug 261984 'Not "updating" Favicon, after a Website has changed the Favicon' Trying to second guess comment 0 and comment 1 , I suggest that there is a request for Necko to follow de jure standards only. De facto standards should be considered on their own merits or implemented through extensions.

this bug has nothing to do with necko.

Sorry

Mozilla.org is serving their favicon.ico with the incorrect MIME type "text/plain"... shame on them!

This feature is really a shame. I never thought that Firefox would have such a bad behaviour (I used to laugh at Internet Explorer for doing such a stupid assumption). My logs are full of 404 because of this and this is not standard compliant. Favicons have to be referenced using the proper html tag. Please explain why it is a WONTFIX ? Are badly referenced favicons so important to end users that we can slow down both users and servers ?

(In reply to comment #12) > Please explain why it is a WONTFIX ? Are badly referenced favicons so important > to end users that we can slow down both users and servers ? The issue of Firefox requesting favicon.ico on every page view (even when favicon.ico returns a 404) is discussed in bug #260500. That bug is still open.

> Please explain why it is a WONTFIX ? Are badly referenced favicons so important > to end users that we can slow down both users and servers ? After reading a lot on the subject, I have come to the conclusion that the reason is mostly ideological. Firefox goal is to provide a popular (i.e. with many users) browser at the expense of interoperability and standard compliance (forgetting what made Mozilla popular in the first place). As you can see in Mike Connor's reply, when there is a choice to do between basic user satisfaction and standards compliance, the basic user's choice is always chosen, even if this user doesn't realize the long-term effects, and without any sanity check. The bug was closed 4 hours after it was opened. It's good to see a fast reply, but I don't think the question has been seriously studied on a technical point of view.