New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 74 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Chrome requests favicons on every request on pages that don't have a favicon

Reported by jgc.crou...@gmail.com, Mar 25 2010

Issue description

Chrome Version       : 5.0.356.2 dev ( Linux ) AND 4.1.249.1036 (41514) ( 
Windows XP )
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: Not Tested
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. Install Mod Deflate for Apache
2. Enable Mod Deflate using the .htaccess file
3. Access a PHP script from the directory with the mod enabled using Chrome

What is the expected result?
PHP script is executed once.

What happens instead?
PHP script is executed twice.

Please provide any additional information below. Attach a screenshot if
possible.

There is only one request in the Apache logs from the browser. So the 
multiple running must be something to do with the response Apache is 
getting ( or not getting ) from Chrome.

I have tested it with a simple script that just logs when it is run.

In Chrome the script appears to run twice, where as in other browsers it 
only runs once.
As soon as mod deflate is disabled, the script only runs once when loaded 
from Chrome.



 

Comment 1 by thakis@chromium.org, Mar 25 2010

Can you attach your script?
I have done some further investigation by taking more things out of the equation. 
It is now apparent that the server was causing a redirect back to the script because 
there was no favorite icon due to the handling of error pages.

It seems that Chrome attempts to load the file on each request ( hence the two loads 
)
Where as Firefox and IE cache the fact that the file does not exist or is invalid 
which also hid the problem.
I have confirmed on a system that has not accessed the page in the past that it does 
happen on Firefox and IE but only on the first load.

Still the interesting point about disabling mod deflate temporarily fixed the 
problem. I am wondering if this was due to some form of caching, as 24 hours later 
after initially fixing the problem by disabling mod deflate it has returned.

Based on all of this I would say the problem is due to Chrome not remembering the 
favicon does not exist or is invalid and it is not a problem with Apache or Mod 
Deflate. 

Comment 3 by thakis@chromium.org, Mar 26 2010

+ someone familiar with the cache.

I would say that no spec says that the existence of favicons needs to be cached somehow, and servers shouldn't 
rely on how specific browsers do this. Hence, I think this is bug is WontFix. eroman, what do you say?

Comment 4 by horus...@gmail.com, Mar 26 2010

From testing - Chrome does actually cache the favicon once the site delivers one.

The issue is more that Chrome keeps requesting a favicon on each page load if it
didn't get one the last time (regardless of whether it's because of a 404 or invalid
content for a favicon) - this means 2 HTTP requests for every page load - multiply
that by the number of websites out there that don't have favicons, and you are now
introducing unnecessary overhead.

This is probably why other browsers, like FF and IE, don't request the favicon more
than once in a single session to a website, regardless of the result of that request.

Comment 5 by thakis@chromium.org, Mar 26 2010

Labels: -Area-Undefined Area-Internals Internals-Network
Status: Untriaged
Summary: Chrome requests favicons on every request on pages that don't have a favicon
I guess that's a reasonable bug. Let's see what triage says.

Comment 6 by wtc@chromium.org, Apr 5 2010

sky: could you take a look at this bug?  It is related to whether Chrome
remembers the fact that the favicon for a site doesn't exist or is invalid.

Comment 7 by sky@chromium.org, Apr 5 2010

Status: Assigned
Yes, it's on my list of things to do this week.

Comment 8 by Deleted ...@, Aug 9 2010

We have GET requesting a CGI-script two times (sometimes). I think it is related to this bug report, so I do not file a new bug.

Comment 9 by Deleted ...@, Feb 20 2011

I am seeing this bug myself, but I believe servers/scripts are handling request improperly. View this example of a one-page request from Chrome and Firefox.

Chrome requests the page, then the favicon. It then sends a HEAD request to that page. My server was at default configurations, and was treating the HEAD calls like GET or POST -- The script executed!

You can see that Firefox does not make this HEAD call below.

Scripts (or server configs) need to check for HEAD requests and deal with them as needed. They are a standardized request.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4

Chrome Request To listings.php?featured=1
71.60.236.20 - - [20/Feb/2011:12:52:12 -0500] "GET /listings.php?featured=1 HTTP/1.1" 200 1090 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.82 Safari/534.16"
71.60.236.20 - - [20/Feb/2011:12:52:15 -0500] "GET /favicon.ico HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.82 Safari/534.16"
71.60.236.20 - - [20/Feb/2011:12:52:15 -0500] "HEAD /listings.php?featured=1 HTTP/1.1" 200 - "-" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.82 Safari/534.16"

Firefox (and others) Request to listings.php?featured=1
71.60.236.20 - - [20/Feb/2011:12:58:34 -0500] "GET /listings.php?featured=1 HTTP/1.1" 200 1090 "-" "Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre"
71.60.236.20 - - [20/Feb/2011:12:58:38 -0500] "GET /favicon.ico HTTP/1.1" 200 450 "-" "Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre"
Same problem on Chrome 10.0.648.133 beta (Windows 7)
Chrome version: 12.0.733.0 dev
I just wrote a small async web server with Mono/.NET 4.0 runtime.
It looks like Chrome opens two TCP connection to web server, but only one of them is used for actual communication. If you stop browser from opening web page, the main connection will be dropped while the second one (not active one) still gonna remain for some time 5-15 secs (probably 10 secs).

Is this optimization or bug?
@David.Ab...: regarding comment #11, that sounds like the "backup TCP connection" optimization. If you go to options->Under the hood and disable the "Predict network actions to improve page load performance" I believe it will be disabled. If you are on an older build of chrome, the feature will be called "DNS prefetching" instead.

Comment 13 by Deleted ...@, Dec 7 2011

chrome 15.0.874.121 m
I just encountered exactly same issue, but it showed up to be problem related to Firebug Lite v 1.4.0. I tried with and without icon and always same result, so "deactivate" Firebug was the cure. Not sure if it will help others, but might be good idea to look at active add-ons.

Comment 14 by bov...@gmail.com, Feb 1 2012

I see the same issue with version 16.0.912.77 m (Windows).  The server consistently returns 404 for the favicon request, and the browser keeps requesting it with every page load.  

Comment 15 by Deleted ...@, Mar 14 2012

I am also facing the same problem and due to this my site crashes as we have used URL rewrite using .htaccess and any invalid request to our site removes session. Best solution is if <link> attribute is provided in HTML then and then chrome should send request for facicon. It should not send request on its own. It should be as per the configuration of site owner.
same here: chrome 17.0.963.83 m
to by pass this i create a favicon.ico file

Comment 17 by dhw@chromium.org, Apr 11 2012

 Issue 122949  has been merged into this issue.
can we get some more support for removing this unnecessary request? i'm sure it's always cluttering and adding (x) amount of noise to logs everywhere. wasting needless resources.

Comment 19 by Deleted ...@, Oct 22 2012

Yes, this really needs to be looked at. In the absence of HTTP/1.1 support on the server this generates (and subsequently tears down) an extra TCP connection for every page view. It's a source of gross inefficiency.
This bug actually causes a race issue here (I work for a web development company) server-side leading to some form posts being rejected. There probably is some better fix for us rather than ensuring we have favicons but I think this issue should be fixed in Chrome too.
For those of you who are experiencing issues, it would help to have a net-internals log.

See http://dev.chromium.org/for-testers/providing-network-details for details.

There maybe multiple underlying causes for the same symptom.
it's pretty clear. /favicon.ico is requested on every page request. stop this.

Comment 23 by Deleted ...@, Oct 23 2012

I've created a net internals log showing this regardless.
favicon-bug.json
1.3 MB View Download
Cc: rvargas@chromium.org
#23: Thanks for the net-internals log. In this case the behavior is the same as what I observed: a 404 is returned without any caching headers. 

According to HTTP specs, 404 response codes should not use freshness heuristics on 404 responses, so we are doing things correctly at the caching layer. Basically, we can't use the cached negative response.

That being said, we may be able to do some hacks at the icon fetching layer to use the stale 404 response in this case.
Also, it doesn't look like there is a Last-Modified header in this case, so heuristic caching also wouldn't work under the normal approach. We should see how other browsers handle this behavior, however.
Just tried with a site that had similar non-cacheable 404s in Firefox 16.01. In this case the favicon.ico was not refetched during the session. New sessions would re-retrieve it. So, there is probably some icon-specific caching that is going on separate from HTTP cache. 

Comment 27 by Deleted ...@, Oct 23 2012

Yes, I think Chrome's behavior is correct in general, it's just this particular case with favicon which needs special treatment. Trying this with IE9 it does the same as Firefox and caches the 404.
I don't think the problem is about http caching. Why do you think that browsers must fetch a favicon from every site?

Comment 29 by dsero...@gmail.com, Oct 24 2012

kofreestyler, because users expect their browsers to display sites' favicons?

Comment 30 by Deleted ...@, Oct 24 2012

I'm using Chrome Version 22 and it keeps on making 2 request to the server, one a GET and then HEAD.

::1 - - [24/Oct/2012:23:38:24 +0300] "GET /sapama/en/properties/myproperties/return_property_features_view HTTP/1.1" 200 25268 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4"
::1 - - [24/Oct/2012:23:38:24 +0300] "HEAD /sapama/en/properties/myproperties/return_property_features_view HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4"

How can I fix this? Do I have to test for HEAD request in my server?

Comment 31 Deleted

Comment 32 by xprom...@gmail.com, Feb 28 2013

i using chrom v 25.0.1364.97 m

in apache log i saw for 2 response like this

80.89.129.114 - - [28/Feb/2013:23:12:58 +0700] "GET /de/bc/germany/busket/paypal/?tttttttt=1 HTTP/1.0" 200 1029 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22"
80.89.129.114 - - [28/Feb/2013:23:12:59 +0700] "HEAD /de/bc/germany/busket/paypal/?tttttttt=1 HTTP/1.0" 200 514 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22"


for each user query.
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network

Comment 34 by sp1d...@gmail.com, Apr 10 2013

Just wanted to let you know - those of you that starred this issue, if you respond with a 410 instead of a 404, Chrome will not request the favicon again.
Owner: mef@chromium.org
Changing owners from sky - this looks like a good warmup bug for mef to tackle. 

Comment 36 by mef@chromium.org, Apr 26 2013

Status: Started
I think correct Chrome behavior would be to only request a favicon file if referred in HTML:

<link rel='shortcut icon' type='image/x-icon' href='/favicon.ico' />

Also note that replicating this issue does not require Apache at all. Simply put, anything answering port 80 gets these unsolicited favicon requests, e.g. my teapot.
Another issue i have with this, is that the F12 inspector does not show this hidden activity on the Network tab. Returning error 404 or 418 makes no difference whatsoever.
> #37 barrystaes
> I think correct Chrome behavior would be to only request a favicon file if referred  in HTML:
>
> <link rel='shortcut icon' type='image/x-icon' href='/favicon.ico' />

we can not add it fo ajax reques
I haven't looked too deeply into how chrome parses the DOM when rendering, it wouldn't add to extra parsing overhead to recognize the shortcut would it?
Another issue i have with this, is that each new favicon.ico request is a new (why?) session. And because each session stays open at the server for some extended period of time, this is a huge waste of resources. Each user click, each request.

Comment 42 by mef@chromium.org, May 8 2013

I've tried with Firefox 20 and IE 10 and they both don't request missing
favicon.ico on every page request. Firefox flags missing icon in memory,
so after restart it requests it again.

IE seems to store missing icon flag in disk cache, so it survives restart, and
re-requests missing favicon only clearing browser cache.

Per discussion with sky@ and cbentzel@ I'm implementing the change to flag favicons returning http status 404 in memory and don't re-request them until user either closes the browser or forces reload by clicking shift-refresh.
Note that this W3C QA page mentions that "Putting the favicon at a predefined URI" is discouraged, and the HTML link tag is also suggested here.
http://www.w3.org/2005/10/howto-favicon
I personally agree with the above.

Which is why i would like to learn whether the above issue resolution is a temporary measure or considered a permanent fix, and -even more so- if the latter i'd like to hear the motivation to load the fixed url, seemingly regardless of HTML link tag.
I'd like to understand.
Sorry for spamming this issue..
For reference, other browsers only load `/favicon.ico` optionally, and by default thats disabled. (source http://en.wikipedia.org/w/index.php?title=Favicon&oldid=554726736#How_to_use )

^ Firefox only accepts favicon.ico in the web site's root without a <link> tag if the setting browser.chrome.favicons is set to true in about:config. The default value is true. If set to false, these favicons are ignored.
^ Opera loads /favicon.ico only if Multimedia/Always load favicon option in opera:config is set to 1. See Opera Support page for more details.

I'd like to see Chrome behave like (pre-chromium) Opera here.

Comment 45 by mef@chromium.org, May 13 2013

Chrome's behavior in regards to predefined "favicon.ico" vs <link rel="icon"> is not the subject of this issue. Chrome DOES recognize <link rel="icon"> and DOES NOT request predefined favicon.ico in such case.

This particular issue is about Chrome's relentless requests for favicon if server doesn't have it.

Project Member

Comment 46 by bugdroid1@chromium.org, May 15 2013

------------------------------------------------------------------------
r200194 | mef@chromium.org | 2013-05-15T08:37:48.461996Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/favicon/favicon_handler_unittest.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/web_contents.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/fetchers/multi_resolution_image_resource_fetcher.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/web_applications/web_app_ui.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/extensions/shell_window.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/fetchers/multi_resolution_image_resource_fetcher.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/metro_pin_tab_helper_win.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/extensions/shell_window.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/image_messages.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/metro_pin_tab_helper_win.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/android_webview/browser/icon_helper.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/android_webview/browser/icon_helper.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/create_application_shortcut_view.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/ash/launcher/launcher_favicon_loader.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/create_application_shortcut_view.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/favicon/favicon_service.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/favicon/favicon_service.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/notifications/message_center_notification_manager.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/image_loading_helper.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/favicon/favicon_tab_helper.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/notifications/message_center_notification_manager.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/favicon/favicon_tab_helper.h?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.cc?r1=200194&r2=200193&pathrev=200194
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.h?r1=200194&r2=200193&pathrev=200194

Don't request missing favicon on every page request. 
Mark Favicon as 'Unable to Download' if server returns HTTP status 404 and
don't try to download it again until user closes the browser or clicks 'Shift-Reload'
(RELOAD_IGNORING_CACHE). 

Firefox 20 and IE 10 don't request missing favicon.ico on every page request. 

Propagated HTTP Status Code from MultiResolutionImageResourceFetcher all
the way up to FaviconTabHelper, which required extension of 3 interfaces. 

BUG= 39402 
TEST=FaviconHandlerTest.UnableToDownloadFavicon

Reviewers:
sky@chromium.org - Overall CL, chrome/browser/*, content/browser/*
palmer@chromium.org - content/common/image_messages.h
joi@chromium.org - content/public/browser/web_contents.h
jamesr@chromium.org - content/renderer/*, webkit/glue/*
mnaganov@chromium.org - android_webview/browser/icon_helper.*

Review URL: https://chromiumcodereview.appspot.com/14322023
------------------------------------------------------------------------

Comment 47 by mef@chromium.org, May 15 2013

Status: Fixed

Comment 48 by Deleted ...@, Jul 20 2013

I am still facing the issue? What has been fixed and how? Please please explain. 

I am using 28.0.1500.72 m version of Chrome.

I have tried almost all the ways to set a fav-icon but nothing works for me.

Comment 49 by mef@chromium.org, Jul 22 2013

Labels: M-29
It has been fixed in version 29.

Comment 50 by juan...@gmail.com, Sep 16 2013

I'm using version 29, and we still face issues related with the way Chrome handles missing favicon.

We have no favicon in our server. We have an apache server acting as front-end, with a rewrite url rule, so when Chrome asks for "/" it is redirected to "/subcontext". Inspecting the access logs, we see that Chrome adds to each request an additional one for "/" and gets redirected (302) to "/subcontext". By adding a condition to exclude /favicon from the rewrite rule, we see that Chrome stop adding this additional requests.

Maybe the fix in version 29 does not takes into account possible redirections?


Comment 51 Deleted

Comment 52 by sp1d...@gmail.com, Apr 2 2014

looks like line 189 of favicon_tab_helper is to blame here... it only takes into account 404.
Project Member

Comment 53 by bugdroid1@chromium.org, Apr 30 2014

Labels: merge-merged-git-svn
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/971b2e973f45bb207dcdb13fcd0b4e0020b89521

commit 971b2e973f45bb207dcdb13fcd0b4e0020b89521
Author: cimamoglu@chromium.org <cimamoglu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Wed Apr 30 12:10:58 2014 +0000

Do not attempt to download favicons with 404 status in WebView

This issue was fixed for Chromium ( crbug.com/39402 ). This patch gets the
relevant parts of the fixing patch for Android WebView.

BUG= 39402 

Review URL: https://codereview.chromium.org/255503004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267192 0039d316-1c4b-4281-b951-d872f2087c98


#50: favicon fetching will likely follow redirects, but what does the redirect to context/ actually result in a 200 or a 404?

#54: I'm somewhat surprised that we fetch favicons at all in WebView. It seems like this is more of a browser-related behavior than a WebView behavior. 

Comment 56 Deleted

Comment 57 by ma...@mazurok.com, Dec 13 2014

Server side: Node.js
Client side: Chrome 39.0.2171.95 m
Every time I try to load the page, server gets 3 requests. First with url="/", and then two requests with url="/favicon.ico".

Same server, but on client side running clean portable build of Chromium Version 39.0.2150.5 (7d466dc36d619ad23f32fabff9fc9bab25fbab58) (64-bit).
Server gets two requests per every page load. First with url="/", and then two requests with url="/favicon.ico". Same issue with clean portable Chrome Version 39.0.2171.95.

BUG IS NOT FIXED.
And must be reopened. Thanks.
I can't repro on M39 stable - see a single favicon request the first time I navigate to a page, which gets a 404 response, and then no others until restart.  You are returning a 404 error, right?

Could you upload a net-internals log of this happening?  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Comment 59 by ma...@mazurok.com, Dec 13 2014

No, I don't, seems like my fault.. But FireFox and IE sends only ONE request after trying to load favicon.
FF sending about three requests for favicon in first load.
IE trying to load favicon several times when I reload the page, and "give up" after that.

First attachment is the simplest server on node.js.
You can see increasing number of requests here: http://54.69.95.79:8080/.
Second attachment is logs from portable Chrome Version 39.0.2171.95. Hope it will help.
testServer.js
357 bytes View Download
net-internals-log.json
2.0 MB Download
I only see one favicon request there, not the two you indicated.  And the server is returning a 200 response, which is rather weird, and violates the HTTP spec.

That having been said, we probably shouldn't be re-requesting the favicon in that case, either because of the mime type (If we check that for favicons) or because we receive the entire response sucessfully and it's not an icon.  There's no real standard here to key behavior off of, unfortunately.

Comment 61 by kenmo...@gmail.com, Mar 14 2015

I'm also encountering this same 100% reproducible issue using a simple node.js web server.

Chrome version 41.0.2272.89 (64-bit)

Comment 62 by ma...@mazurok.com, Mar 14 2015

kenmo...@gmail.com, it is because you shuold return 404 error if you have no favicon. else chrome will try to get it again and again. but if you will return 404 error - chrome will remember this.
My setup:

- web server (OpenBSD's HTTPd)
- serving single file: index.html which content is:

<html>                                                                                                                                                                                                             
    <body>                                                                                                                                                                                                         
        <h1>Test</h1>                                                                                                                                                                                              
    </body>                                                                                                                                                                                                        
</html>

I do *not* provide a link to the 'favicon.ico', nor do I *ever* intend to - it is neither a requirement, nor is it in any working draft.

This is clearly a bug in Chrome, when accessing a page, it automatically "assumes" the existence of 'favicon.ico' and tries to get it.

Please, only use the HTML code for any files - do *not* try to pre-load anything that's not defined!

This is plain wrong and really annoying to see 404 in your server logs generated automatically by a web browser! Stick to the W3C standards.

Please, *STOP*!

Thank you.
BTW, this happens on an up-to-date Chromebook.

Comment 65 by Deleted ...@, Aug 11 2015

Version 44.0.2403.130 m
Windows 7

I find with Charles Proxy that every 3rd party domain, that is, app, pixel tracker, analytics tag etc, also gets a request to /favicon.ico  

Comment 66 by Deleted ...@, Nov 18 2015

issue happens at Chrome Version  46.0.2490.86 m (64-bit)
windows 10 Pro

I'm using node.js

exemplo simples:
[code]
var http = require("http");

var server = http.createServer(function(request, response) {

    console.log('inside createServer\n'); //it shows 2 times if open 127.0.0.1:30000 in chrome
        response.writeHead(200, {"Content-Type": "text/html"});
        response.write("<!DOCTYPE html>");
        response.write("<html>");
        response.write("<head>");
        response.write("<title>Hello World Page</title>");
        response.write("</head>");
        response.write("<body>");
        response.write("Hello World!");
        response.write("</body>");
        response.write("</html>");
        response.end();

});

server.listen(30000);
console.log("Server is listening");
[/code]
so its been 5 years still not fixed please fix this
Ahaha, today is 2017th year and bug is not resolved :) The same issue. Each time after post request I see in fiddler get favicon request. Fix it, please.
This iS NOT FIXED!!!!
2017 and know one needs a browser asking for something that is not on ANY server!!! PLEASE PLEASE FIX IT AND STOP STOP asking for /favicon.ico 
for example a POST is waiting for a response and wastes it reply with a /favicon.ico in a bug reply from Chrome!
 
Reopen.... this bug is not fixed

Comment 71 by ulime...@gmail.com, May 22 2017

Has this bug never been fixed or recently reintroduced?

Comment 72 Deleted

This bug still there and not fixed (Today is 2017,Aug 29).
My laptop environment is Mac OSx 10.12.5 and my google chrome version is 60.0.3112.113 (the latest stable version).
I use nginx as my web server and my config is simple
location / {
try_files $uri =404;
}

When I use safari, there is no this problem.
When I use chrome, it will fetch the favicon.ico and return 302, then it will fetch another cached file.

1.png
168 KB View Download
looking for https://stackoverflow.com/questions/8247842/session-data-lost-in-chrome-only
The issue is with PHP getting the request that did not match a file and then not properly handling 404's correctly. I had to tell Nginx to match any URL with favicon.ico and then return a 404.

Here is my line for Nginx:

 if ($request_uri ~ 'favicon') {
            return 404;
 }

Comment 75 by rrent...@gmail.com, Sep 13 2017

This needs to be addressed as it should not be a request unless a site has it as part of the requests within the content of a page.  The browser taking its 'own actions' without a directive to do so is a bug.

Sign in to add a comment