279891 - favicon.ico requested even though it is not referenced in web pages

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Damien]

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.

Comment 1

[Robert Kaiser]

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.

Comment 2

[Ng Ming Hong]

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.

Comment 3

[Håkon Nessjøen]

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

Comment 4

[Mike Connor [:mconnor]]

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.

Comment 5

[Aiko]

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.

Comment 6

[Wolf [:wolf]]

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

Comment 7

[Felix Miata]

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;}

Comment 8

[Ben Fowler]

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.

Comment 9

[Mike Connor [:mconnor]]

this bug has nothing to do with necko.

Comment 10

[Ben Fowler]

Sorry

Comment 11

[Dan Tobias]

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

Comment 12

[Jonathan Ernst]

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 ?

Comment 13

[Thomas Rutter]

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

Comment 14

[Damien]

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