Closed Bug 260500 Opened 20 years ago Closed 19 years ago

Browser requests favicon.ico on every page view

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: 32768, Assigned: vladimir+bm)

References

Details

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
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
Severity: minor → major
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".
Flags: blocking-aviary1.1?
not really sure where this should go, but reassigning in the hope that it might
get someone to look at it.
Assignee: firefox → vladimir+bm
Component: General → Bookmarks
QA Contact: general → mconnor
*** 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.
Flags: blocking-aviary1.1? → blocking1.8b4?
not able to reproduce on trunk. minusing unless someone can show it's still a
trunk problem.
Flags: blocking1.8b4? → blocking1.8b4-
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.
Status: NEW → RESOLVED
Closed: 19 years ago
OS: Windows XP → All
Resolution: --- → WORKSFORME
> 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
QA Contact: mconnor → bookmarks
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.
You need to log in before you can comment on or make changes to this bug.