I would propose that we put a blank icon file at /favicon.ico to avoid 404 errors from broken browsers not requesting the icon from the appropriate place. Blank because anything else would be "hard" for themes and users to replace, and not replacing a non-blank icon would hurt branding on some sites. There is a rather bloated blank icon file at http://www.sourceopen.com/favicon.ico but it can be made as small as 200 bytes with a little tweaking. I would be attaching my sample ico file here, hence the 'patch' status, but apparently we cannot attach ico files any more. Consider the linked file to be the submitted patch, although a shrunken version would be far more appropriate.

#92 favicon404-174940-92.patch906 bytesmgifford
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch favicon404-174940-92.patch. Unable to apply patch. See the log in the details link for more information. View
#78 174940-78-set-good-default-for-favicon.patch1.13 KBgagarine
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View
#63 htaccess-favicon-404-fix-174940-drupal5.patch1003 bytesmatt@antinomia
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch htaccess-favicon-404-fix-174940-drupal5.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View
#56 htaccess-favicon-404-fix-174940_1.patch943 bytesgpk
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_1.patch. View
#56 htaccess-favicon-404-fix-174940_0_followup.patch762 bytesgpk
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_0_followup.patch. View
#52 htaccess-favicon-404-fix-174940_0.patch820 bytesgpk
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_0.patch. View
#51 htaccess-favicon-404-fix-174940.patch755 bytesgpk
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940.patch. View
#22 favicon.patch2.31 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_3.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View
#21 favicon.patch2.19 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_2.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View
#3 favicon.patch1.33 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View


Pasqualle’s picture

Status: Needs work » Active

I have many watchdog entries for favicon.ico on my live drupal 5 site.
the icon is displayed correctly, so I do not understand it. I even see watchdog entries for myself, and I am using firefox (not a broken browser)
(note: i have i18n module enabled)

so if it is still an issue in drupal 6, than it should be fixed

1. need to know why the problem exist
2. need correct solution

webernet’s picture

Some browsers (IE?) seem to look for the /favicon.ico directly rather than the "shortcut icon" linked to in the page header.

Maybe if we receive a request for a non-existent /favicon.ico, we can redirect to the appropriate theme provided favicon?

RobLoach’s picture

Title: root /favicon.ico accounts for majority of 'page not found' errors » Root /favicon.ico accounts for majority of 'Page not found' errors
Component: base system » system.module
Priority: Minor » Normal
Status: Active » Needs review
1.33 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View

The attached patch creates a menu callback at "favicon.ico" that will refer the request over to the currently selected theme's shortcut icon. If the theme doesn't have a favicon, a 404 is returned.

webchick’s picture

Hm. That will invoke a Drupal boot strap on each one of those 404s. Yikes. :\ Though I'm not sure of another workaround that preserves the site's branding. A blank (or Druplicon) favicon.ico in the root would stop the 404s, but then in order to ensure users of buggy-assed browsers see the right thing, people would need to "hack" core and put their own favicons in two places.

moshe weitzman’s picture

i don't mind shipping a blank icon in root and asking users to symlink the real one if they caare about these broken browsers.

zeta ζ’s picture

What about putting the blank.ico in misc/ and redirecting to it in .htaccess, asking users to edit … (some servers don’t have symlinks)? Can the theme system modify .htaccess when a theme is selected, to redirect to its own favicon? We would need to point out that dynamically selected themes (eg. by taxomomy, or page-*.tpl.php) would not affect the favicon sent to these browsers, so the favicon of the chosen main theme should be made appropriate to the whole site.

dvessel’s picture

A quick search reveals that it's due to people bookmarking your site. The browser tries to grab the file without any reference to where it is actually linking to.

An .htaccess change would be the best bet.

webchick’s picture

Actually, if we're going to do that, let's put it in sites/default/files so that you don't have to "hack" core to change your favicon.

markus_petrux’s picture

IMO, minimal resource consumption should be wasted to resolve these favicon.ico requests.

An empty /favicon.ico works. Then, once you have a custom favicon, it's only matter to replace that one. You may also tell Apache to send cache-control headers, so these files rest in proxy/browser land for a long time.

RobLoach’s picture

Status: Needs review » Needs work
RobLoach’s picture

Version: 6.x-dev » 7.x-dev

Moving this to Drupal 7 as it's just way too late for Drupal 6.

This is just a quick note that there are actually many web services out there (including Delicious), that often assume that a root favicon.ico is available and use that when displaying an icon to the user...

sparr’s picture

Version: 7.x-dev » 6.x-dev

"way too late" for 6.0 maybe, but this isnt exactly a massive change, I don't see why 6.x is not still a reasonable target for any of the proposed solutions.

catch’s picture

Version: 6.x-dev » 7.x-dev

Even if it eventually gets fixed in 6.x, since we have a 6.0 release, it'll need to go into 7.x then be backported.

gpk’s picture

re. #7, I have found that you can generate requests for /favicon.ico without trying to bookmark it. IE7 always requests /favicon.ico the first time you visit a site, and if you want the icon to be displayed in IE7 immediately someone lands on your site, you had better have it available at /favicon.ico. So if you are running multisite then this either means .htaccess skullduggery or defining a callback for /favicon.ico à la #3. (On subsequent visits, IE7 appears to pay attention to the <link rel="shortcut icon" ... > element in <head>.)

markus_petrux’s picture

Haven't checked with IE7, but an empty favicon.ico (0 bytes) does the job for other browsers, reasonable (IMO) while the final favicon.ico is coming from the web site dessigner...

Zach Harkey’s picture

What about multi-site installations where the designer can't just replace the default blank /favicon.ico?

RobLoach’s picture

Replacing an existing favicon.ico would also count as hacking core.

Zach Harkey’s picture

Ok, I have solved this favicon.ico issue for all of the sites on my multi-site installation with the following mod_rewrite rule in .htaccess:

  RewriteRule ^favicon.ico sites/%{SERVER_NAME}/favicon.ico [NC,L]

This will automatically redirect any queries for /favicon.ico to /sites/example.com/favicon.ico

- Allows custom /favicon.ico for each site in a multi-site installation, just by putting a favicon.ico in the appropriate site directory.
- No system resources or callbacks
- No more 404 error messages overrunning the error logs
- Easy (improvement)

- Doesn't solve the problem for subdirectory-style sites (e.g. .example.com/site3 will inherit the example.com favicon). These kinds of sites will be in the same boat they are now.
- Doesn't leverage the existing upload form provided in the theme admin page. This is because this upload form renames the favicon.ico files to themename_favicon.ico. This could be solved by making the favicon a system setting instead of a theme setting.

wretched sinner - saved by grace’s picture


RobLoach’s picture

This has been a problem for a while..... http://drupal.org/node/61728

I think the best solution would be the menu solution I provided at #3 along with a note in .htaccess to use the rewrite if you want to skip the menu item at favicon.ico.

RobLoach’s picture

Status: Needs work » Needs review
2.19 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_2.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View

Thanks, Zach. The attached patch does two things:

  1. Adds a menu item for favicon.ico to return the theme's shortcut icon.
  2. Adds a note in .htaccess about how to skip the Drupal bootstrap when the favicon.ico requests are made, while still returning the correct shortcut icon.
RobLoach’s picture

2.31 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch favicon_3.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View

Morbus brought up a good point: ${SERVER_NAME} doesn't always reflect your respective sites directory. The solution is to add a RewriteCond for the desired domains, and have the user manually write in their favicon path. This patch adds instructions on how to do that.

alpritt’s picture

Status: Needs review » Needs work

I'm not comfortable with having the menu call in there. We shouldn't have to compromise performance because of problems on the browser (or web app) end. The fact that they can then override this in .htaccess should not be a reason to cause the performance issue in the first place.

The commented out .htaccess stuff looks sensible on its own; if not a perfect solution.

gpk’s picture

>not comfortable with having the menu call in there
That was my initial feeling, but then on the other hand at the moment the request for /favicon.ico generates a 403, which could be rather *more* processing than what is proposed here, if we could get the simple header response to cache somehow?

The other question in my mind is whether the browser will respond properly to a 302 in this situation. Given we've got this far I presume the answer to that question is "yes" but I've not got round to testing it myself yet.

alpritt’s picture

Good point. Therefore related to http://drupal.org/node/76824

davidwhthomas’s picture

Here's the fixed .htaccess rewrite rule to prevent rewriting when the request is for the favicon itself

#don't redirect if request is for the file itself
RewriteCond %{REQUEST_URI} !^/favicon.ico$
RewriteRule favicon.ico$ /favicon.ico [NC,L]

Alternatively, you can just copy your favicon.ico file to your drupal root.


Dries’s picture

A menu callback is way too expensive -- it basically requires us to do two bootstraps for every page view!

How about we put the favicon.ico in the root directory and be done with it?

gpk’s picture

>How about we put the favicon.ico in the root directory and be done with it?
Not ideal for multisite...

>A menu callback is way too expensive -- it basically requires us to do two bootstraps for every page view!
The /favicon.ico is only requested relatively occasionally, e.g. by IE7 when you first land on (any page of) a site (despite what may be defined as the location of the icon in the page source). At the moment Drupal serves up the full 403 page when /favicon.ico is requested, which is worse than the proposed menu callback patch.

A *blank* (empty) favicon.ico in the root directory does at least stop the 404s (this is what I have used), the question is then whether it's worth trying to fix this properly in core (i.e. to work round IE!) either by a menu callback or by .htaccess. Note that IE7 appears to ignore the <link rel="shortcut icon" ... > stuff for the entire duration of your first visit to a site, so if we *don't* come up with something better than providing an empty favicon.ico then this *will* result in the favicon you have defined in your theme not being shown to IE7 visitors until they come back for a second visit. (Thanks, MS!) Also note comment above re. digg etc.

moshe weitzman’s picture

I'm not saying that menu callback is the best solution, but "two full bootstraps" is not that big a deal once #259412: Total module system revamp lands. Check it out.

Perhaps we put this file in root and multi-site operators who care about site specific favicons can remove the file and install a contrib module that does menu callbacks.

gpk’s picture

That was kind of where I was heading :). I think it would have to be the blank one that we put in root (was that what you were saying?) since Drupal won't be able to upload a custom icon there.

A bit of documentation (maybe on the configure theme pages) would help greatly to explain the presence of the blank /favicon.ico. Perhaps a one-liner with a link to a page on d.o would do it.

RobLoach’s picture

gpk @ #28: Also note comment above re. digg etc.

Web services that assume that a favicon.ico are available is my primary concern here. Delicious being one of the large sites that uses Favicon to display thumbnail logos...

moshe @ #29: Perhaps we put this file in root and multi-site operators who care about site specific favicons can remove the file and install a contrib module that does menu callbacks.

Removing or replacing a file in core is essentially hacking core. Although we are just removing one file, it seems kind of hackish, not to mention it wouldn't work on multisite systems. I rather liked your latter proposal though.

If we just provide documentation about the .htaccess redirect with conditions on how to send favicon.ico requests to sites/example.com/favicon.ico, then users who care about the favicon.ico requests can simply put in their favicon settings in .htaccess.

In addition to that, I could maintain a module that adds the menu callback for those who don't know enough to add the .htaccess rules. The solution I suggested at #22 does both of these (.htaccess documentation, and menu callback if the .htaccess rule isn't set). The menu callback is only active if .htaccess rule isn't set. Seems like a rather useless contrib module, but hey.

Think we should make the .htaccess documentation into a patch?

moshe weitzman’s picture

So you are willing to ask people to edit .htaccess but not willing to ask people to fiddle with an icon file on the filesystem? i would think that .htaccess is more scary than a graphic file to most people. Furthermore, the .htaccess solution is specific to Apache so you are catering to multi-site apache and not everyone else.

I can't get behind the logic that calls moving a graphic file around "hacking core". For a certain class of problems, changing core is the right fix and this is one of them.

RobLoach’s picture

I guess you're right. So, for single site solutions, provide a default favicon.ico, and have people replace it. For multi-site solutions, have people remove it, and use a contrib module? That seems reasonable to me... Might it be easier to provide the default favicon as well as the menu callback? If people want to skip the Drupal bootstrap, they could just stick in the redirect...

Dries’s picture

I don't see why having the favicon in / is any more hackish or less flexible than having it in misc/. As far as I can tell, it doesn't make a difference for multi-sites.

gpk’s picture

Just to clarify, when talking about a favicon.ico in / we are still meaning a *blank* one? (Because otherwise it will conflict with the theme-supplied one and people will wonder why occasionally they see a Druplicon instead of their custom one --> they are likely to call this a "bug" ... at least a blank icon is just that!).

On its own this would fix the Page not found errors - the original purpose of this issue - without interfering with the theme's favicon. The question of some browsers and web services not properly *displaying* the icon referenced by <link rel="shortcut icon" ... > (as inserted by the theme) is perhaps separate, albeit working round this is a very strong "nice to have" IMO.

Finally, from a quick look at my logs, on one site these errant requests for /favicon.ico amount to 1% - 2% of the total page requests handled by Drupal.

Pasqualle’s picture

maybe removing the watchdog message for favicon could be a possible solution also, because that is the only bug I see here.. could be easier than playing with some dummy image files.
Or is the error logged in apache log also?

Crell’s picture

@#36: It's showing up in watchdog because it's triggering a full second page request in the first place.

Seriously though, I'm confused. The problem is that some buggy browsers are requesting /favicon.ico, even if it doesn't exist and it hasn't been told to. That should be a 2-3 line fix in .htaccess, shouldn't it? If the request is for /favicon.ico, and the file doesn't exist, return a server-generic 404. Problem solved. I'm missing the complicated part.

Dries’s picture

@#35: I was suggesting to move /misc/favicon.ico to /favicon.ico. In other words, not a a blank one. Just like themes can overwrite /misc/favicon.ico, they should be able to overwrite /favicon.ico.

alpritt’s picture

@#38: The problem with just moving the misc/favicon.ico to /favicon.ico is that instead of getting a 404 response, this bug will now reveal a druplicon icon instead. A theme overrides this with a link in the HTML element, but that's irrelevant because browsers with this bug ignore this link and just assume /favicon.ico is the place to look.

Let's sum up the choices:

1. druplicon favicon is put in / rather rather than /misc (with this bug, a druplicon icon is sent instead of just 404ing)
2. menu callback (You send the correct icon, but this is expensive)
3. blank favicon (It's basically a lie)
4. check in .htaccess and then redirecting to the correct file (impossible to do dynamically? Apache specific )
5. we automatically make a copy of the correct file and place it in / when a theme overrides (file permission problems)
6. check in .htaccess and 404 (You don't get the file, but it's cheap. Again, Apache specific.)

Pasqualle’s picture


this bug will now reveal a druplicon icon instead

did you try it? because I saw the watchdog message, but I can not find which browser is doing this, the correct favicon is displayed in browsers. Nobody really investigated the source of this problem..

Dries’s picture

@#39 and @#40: just like Pasqualle, I was under the impression that the broken browser blindly loads /favicon.ico (think 'pre-caching') but that it still gets the correct favicon once the HTML has been received and parsed. The Druplicon favicon would not actually show.

gpk’s picture

Isn't it amazing how such a trivial issue threatens to get out of hand ... :P

To cut to the chase, I'm proposing we go for a combination of alpritt's 3. and 4.

Anyway, first of all I need to apologise because some of my comments (at #14 and #28) were misleading! IE7 generally *does* respect a "shortcut icon" link definition in the page source, it's just that it generally doesn't display the icon until your 2nd visit. Very occasionally it does seem to request /favicon.ico even when the shortcut icon is defined; I don't know why or when.

Also, IE6 always requests /favicon.ico, but I understand it only displays it in the address bar if you bookmark the page (http://www.webmasterworld.com/forum21/11293.htm). IE6 ignores any "shortcut icon" link defined in the page source. Firefox 2 basically just seems to play nicely. It would seem that web services (#31) will blindly request (and display) whatever is found at /favicon.ico. I've also seen lots of requests for /favicon.ico from Google Toolbar running on IE7.

@#41: If the Druplicon is at /favicon.ico then this will display in IE7 and Ff2 if the administrator turns off display of the shortcut icon on the themes page since these browsers fall back to /favicon.ico if no shortcut icon is defined. The same may be true of other newer browsers. Also it seems pretty well certain that it will be displayed by IE6 if the user bookmarks the page, and also (Rob?) by web services. So I think this rules out this option (alpritt's 1.).

Given the varied behaviour of different browsers (see below) I think it's futile trying to accommodate them all to ensure that the favicon always works optimally. There's still quite a lot of IE6 out there, but since it only displays the icon when a page from the site has been bookmarked I don't think that's sufficient justification for getting the theme's favicon to always be available at /favicon.ico. Web services would be a stronger argument, but even so, I think that while it's arguably the optimal solution, trying to get the menu callback option (alpritt's 2.) to work reliably and with minimal overhead would be overdoing it at the moment, at least in core. Maybe this could go in a contrib module (if anyone's up for it - Rob?!) which would allow plenty of testing on D6 or D5 before any decision to go this way in core (bascially I think that going for this in core now would be likely to hold up this issue which then mightn't get fixed).

alpritt's 5. (put the theme's favicon in /) I'm ruling out on the grounds of file permission issues.

Option 6. (check in .htaccess and 404) looks smart but I think risks filling up the Apache error log with these 404s, which I don't think is helpful to admins; apart from that, it would have had my vote.

So I'm coming round to 3. (the lie - a blank favicon - which incidentally seems to be what we have at http://drupal.org/favicon.ico), but it needs some documentation - where? Perhaps the easiest way of doing that is to have (alpritt's 4.) a commented out line in .htaccess for redirecting /favicion.ico to the correct file, something like #22), with a very brief note about favicon handling by clients being buggy, and a link to a page on d.o. somewhere. I'd be happy to draft that up. Goodness knows where to put it!

Finally, some findings follow based on some limited testing and Apache log trawling I did :) Don't forget to clear your cache first if trying out any of this at home ..and make sure there's a responsible adult present at all times ;)


IE7 usually doesn’t seem to request /favicon.ico if the link to the shortcut icon is defined in the document.

If this link is defined and is valid then the favicon only seems to display on the 2nd visit to the site. (This is with the option “Check for newer versions of stored pages: Automatically”, which is the default I think. Of course we can’t control what setting users will have here, but I expect this is the most common. Also I don't know if this actually makes any difference, though it was suggested somewhere that it might.)

If the shortcut icon is not defined in the document then IE 7 will request /favicon.ico and it will display immediately if found.

So if you want a favicon to display in IE7 immediately a visitor lands on your site then make sure that the shortcut icon is *not* defined in the document and put it at /favicon.ico. For example these 2 don’t show the favicon straight away www.google.co.uk, www.bbc.co.uk, whereas this does www.radiotimes.com.

See also http://www.webdeveloper.com/forum/showthread.php?t=122094&page=2.

MSIE 6.0 requests /favicon.ico during first page view on the website.

Firefox 2 seems quite well-behaved, in that it will use and immediately display the icon defined by the shortcut icon link, or failing that, use and display /favicon.ico.

Earlier versions of Firefox (and Mozilla) require the shortcut icon to be defined in the document.

The upshot of this is that if you want the favicon to work on first landing on your site in *all* browsers then you've got a problem unless you do browser detection. The 90% solution would probably be just to use /favicon.ico and make sure that you don't define the shortcut icon link in the document (an IE7 workaround). This probably wouldn't work on older versions of Firefox (and Mozilla).

Crell’s picture

"Fill up the Apache log with 404s" - Why is that a bad thing? The browser is requesting a file that does not exist. A 404 is exactly what should happen in that case, per spec. If the server doesn't have a favicon file now, and is not running Drupal, then it will already be "filling up with 404s". That's not a Drupal problem. If they object to the high number of bad requests from certain browsers, they should encourage their users to not use those browsers. :-) An apache 404 is better than a Drupal 404, since Apache can respond much much faster than Drupal can.

RobLoach’s picture

Great summary, gpk. I'd have no problem maintaining that 10 line contrib module :-P .

gpk’s picture

@#43: It's not so much a bad thing as inconvenient. At the moment I only get entries in the Apache error log if there's a problem I need to know about. And like it or not, IE6 will be with us for a while yet: http://www.w3schools.com/browsers/browsers_stats.asp. I won't die in a ditch over this though!

Dries’s picture

Excellent analysis.

Based on the analysis, I now vote that we fill up the accesslog with 404s. It's better than an empty favicon, IMO.

mcurry’s picture


gpk’s picture

Yeah, filling the Apache error log is certainly a load better than filling the {watchdog} table and I've now come round to this point of view.

This works quite nicely for me (sorry, not a proper patch yet):

In .htaccess, underneath

# Customized error messages.
ErrorDocument 404 /index.php


# Force simple error message for errant requests for non-existent favicon.ico
# (see http://drupal.org/node/xxxxxx). <-- handbook page not created yet ;)
<Files favicon.ico>
  ErrorDocument 404 "The requested file favicon.ico was not found."

This causes /index.php *not* to be used as the error handler for any request for a favicon.ico in or below the Drupal root folder. Note that if mod_rewrite is enabled then this has no effect unless the following change is also made, since the default rewrite rule converts (internally within Apache) any request of the form http://example.com/load-of-rubbish.ext into http://example.com/index.php?q=load-of-rubbish.ext.

So, right at the bottom of .htaccess, in this section:

  # Rewrite URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

insert another RewriteCond immediately after the existing 2 (and above the RewriteRule):

  RewriteCond %{REQUEST_URI} !=/favicon.ico

(This makes sure that the immediately following rewrite rule is not applied if the request is for /favicon.ico.)

Incidentally I noticed that if mod_rewrite is not active then any request for a non-existent URL beneath your domain just brings up the home page instead of the 404 page (so this is an even worse performance issue than when mod_rewrite is active). Which made me think - mod_rewrite is actually not essential for clean URLs to work - you could just do a bit of parsing of the request URI... but that's getting a tad off-topic ...

Dries’s picture

gpk (or somoene else), would you mind rolling a patch for the proposal in #48? I'd be happy to commit that to CVS HEAD.

gpk’s picture

Component: system.module » base system


The RewriteCond doesn't play nicely with Drupal in a folder, don't have any time just now but will try to roll patch with improved RewriteCond later. Probably RewriteCond %{REQUEST_URI} !/favicon.ico$ will work (that should exactly correspond to the earlier Files directive) but not tested yet.

gpk’s picture

Status: Needs work » Needs review
755 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940.patch. View

Actually the RewriteCond was fine, even with Drupal in a subfolder (because in that case the request for /favicon.ico never goes anywhere near Drupal's .htaccess in any case).

In this patch have condensed the ErrorDocument stuff :)

Can sort out documentation of this as a follow-up.

gpk’s picture

820 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_0.patch. View

Actually condensing the ErrorDocument stuff was not such a good idea. If there is an ErrorDocument specified at a higher level e.g. by cPanel, then if it doesn't exist you can end up with a request for e.g. 404.shtml being rewritten as a request for index.php?q=404.shtml ...

So we need to force Apache to do something very simple. Back to plan A.

Dries’s picture

Version: 7.x-dev » 6.x-dev
Status: Needs review » Reviewed & tested by the community

I think this looks good and based on my testing, it works. I've committed it to CVS HEAD.

I've also applied it on my personal blog to test it some more against DRUPAL-6. I think we should apply this to Drupal 6 as well but I'll leave that up to Gabor. I'll report back if I discover any problems.

RobLoach’s picture

Is it just me, or is there an extra quote at the end?

xmacinfo’s picture

I vote to see this in Drupal 5 as well.

gpk’s picture

Version: 6.x-dev » 7.x-dev
762 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_0_followup.patch. View
943 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in htaccess-favicon-404-fix-174940_1.patch. View

@54: My hunch is that that probably means buytaert.net is running on Apache 1.x where I'm on 2.x (2.2.8 to be precise). Omitting the final quote works fine on 2.2.8 and according to the docs should also be fine on 1.x http://httpd.apache.org/docs/1.3/mod/core.html#errordocument.

TBH I'm not convinced that hordes of people will examine the content of the 404 response from such URLs, but attached revised patch fixes it ;) The "followup" patch is just the delta.

Also slightly expanded the comment above the main rewrite rule - it confused me for many months before I got my head (partially) round mod_rewrite. Hope that's OK.

Dries’s picture

Version: 7.x-dev » 6.x-dev

Committed #56 to CVS HEAD. Should probably go into DRUPAL-6 as well.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, committed #56 to Drupal 6 as well.

gpk’s picture

Version: 6.x-dev » 5.x-dev
Status: Fixed » Patch (to be ported)

Per #55. I've not checked if the _1 patch at #56 applies to D5 or not.

RobLoach’s picture

I've put together the contrib module that adds the menu item..... http://drupal.org/project/favicon

EoinBailey’s picture

I tried this module, gave me the WSOD.

gpk’s picture

@61: suggest you open an issue in the project's issue queue with full details of error messages from Apache error log etc. http://drupal.org/node/add/project-issue/favicon

@60: just to note that if this patch does get ported to D5 then to get the module to work it will be necessary to modify one's .htaccess in order to have the request for favicon.ico passed to Drupal and not just throw an Apache 404.

matt@antinomia’s picture

Status: Patch (to be ported) » Needs review
1003 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch htaccess-favicon-404-fix-174940-drupal5.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots. View

Patch for D5 attached. Those favicon 404s are driving me crazy!

slosa’s picture


hedac’s picture

I'm using a multisite installation, drupal 6.

so I don't want the same blank favicon for all the sites... each site should have it's own favicon under sits/eachdomain.com/files for example.

How could I rewrite to each favicon depending on which virtual host is accessing?

RobLoach’s picture

favicon.ico is only used with IE6....... If you set the icon in the theme settings page, then you'll have a different icon for each site. For favicon.ico, you'll want to use the Favicon module.

drumm’s picture

Status: Needs review » Fixed

Committed to 5.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

gagarine’s picture

Version: 5.x-dev » 6.22
Status: Closed (fixed) » Active

D6.22 and full of those line in /var/log/apache2/error.log

[Mon Jul 18 13:35:57 2011] [error] [client 195.186.XX.XX] File does not exist: /var/www/vhosts/site.org/htdocs/favicon.ico
[Mon Jul 18 21:10:01 2011] [error] [client 41.248.XX.XX] File does not exist: /var/www/vhosts/site.org/htdocs/favicon.ico
[Mon Jul 18 23:27:14 2011] [error] [client 41.249.XX.XX] File does not exist: /var/www/vhosts/site.org/htdocs/favicon.ico
gpk’s picture

Title: Root /favicon.ico accounts for majority of 'Page not found' errors » Root /favicon.ico accounts for majority of 'Page not found' errors in Drupal's system log
Version: 6.22 » 5.x-dev
Status: Active » Closed (fixed)

Yes that's the intended behavior now: Drupal usually handles 404 errors, but not for /favicon.ico (see the .htaccess file). The errors are caused by browsers requesting a non-existent file. It's not Drupal's fault the browsers do that!

Changing title of this issue to clarify.

geerlingguy’s picture

@gagarine - If you simply stick a favicon.ico file into your root drupal 6 directory, that will fix the error messages from appearing. Of course, for IE users, that favicon will show up for all sites in the bookmarks, but that's a minor annoyance. I did this just because I was tired of 90% of my apache error logs filling up with 'File does not exist' errors :-/

dynamicdan’s picture

Voting time!... FIND A SOLUTION!

A) - dummy favicon in /misc/ (with default rewrite rule)
B) - default favicon in sites/all/themes/ (with default rewrite rule)
C) - clever theme based rewrite rule solution (without putting strain on drupal/bootstrap stuff)
D) - simple but obvious instructions for handling favicon.ico 404 errors

I suggest a combo of B, C and D. With B being good enough and D being an ok solution.

dynamicdan’s picture

Title: Root /favicon.ico accounts for majority of 'Page not found' errors in Drupal's system log » Set good defaults to help browsers find favicon.ico files
Version: 5.x-dev » 7.9
Category: bug » feature
Status: Closed (fixed) » Needs review

Note: not making a new issue because the history/solutions are here.... somewhere.

Status: Needs review » Needs work

The last submitted patch, htaccess-favicon-404-fix-174940-drupal5.patch, failed testing.

RobLoach’s picture

Version: 7.9 » 8.x-dev
Issue tags: +Don't Hack Core

Yeah, I've just been ignoring the warnings. Would be nice if they went away though......

[Mon Nov 21 10:21:31 2011] [error] [client] File does not exist: /var/www/favicon.ico

But, 8.x first, then 7.x ;-) .

gagarine’s picture

A solution to avoid message in the error log (still in access log) from http://nfolamp.wordpress.com/2010/06/28/apache-favicon-ico-does-not-exis...

Redirect 404 /favicon.ico
<Location /favicon.ico>
   ErrorDocument 404 "No favicon"
cweagans’s picture

Issue tags: +needs backport to D7
gagarine’s picture

Status: Needs work » Needs review
1.13 KB
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View

Here a patch. What do you think?

Status: Needs review » Needs work

The last submitted patch, 174940-78-set-good-default-for-favicon.patch, failed testing.

David Lesieur’s picture

gpk’s picture

@78: that won't work for multisite. Out of interest, how does the rewrite of the /favicon.ico request to the theme folder interact with the Redirect 404 /favicon.ico directive? Also I agree with Crell in #43, if a browser requests a non-existent file and Drupal chooses not to log the error then Apache should. If site owners wish to modify that behavior then fine.

Am tempted to reset this issue to its previous status in #72. The original problem was fixed a long time ago. Any problems caused by the changes that went in 7.x (#76824: Drupal should not handle 404 for certain files) should be posted as a follow-up to that issue. Any further improvements/changes should go in a new feature request for 8.x.

There is also http://drupal.org/project/favicon which might be of use.

RobLoach’s picture

Issue tags: +html5


Assuming /favicon.ico seems like a hack when we could use rel=icon and hook_html_head_alter().

cweagans’s picture

#82 is what we should do to properly support multisite.

gagarine’s picture

Out of interest, how does the rewrite of the /favicon.ico request to the theme folder interact with the Redirect 404 /favicon.ico directive?

Because of the / it's only redirect when we try to acces favicon.ico on the root directory. I don't see why this part will not work for multi-site. Do you speak about the code in comment? For me this is optional, if we can already stop making a useless log entry for each request... I'm happy.

gpk’s picture

>Do you speak about the code in comment?

Per#81, I would also vote for getting a not found error for /favicon.ico in the Apache error log *by default*, but not in the Drupal log. And I'd be happy if there was maybe a line to uncomment to get rid of the error in the Apache error log also.

candelas’s picture

getting this warning in drupal 7.22
thanks for your work :)

jwilson3’s picture

As i see it there are two solutions to the problem:

1) always return a 404 for /favicon.ico via htaccess: -- this is totally unhelpful when there almost always IS a favicon somewhere.
2) let drupal figure out where the favicon is, and return that file.

IMHO, The problem is not that the file doesn't exist, but that Drupal's opinion about where the favicon.ico file should live differs from what the "rest of the world" expects. To Drupal, a favicon almost always *does* exist -- it's just located in a different place. So, if we have the data stored in our own custom location, and we know for a fact that others will be looking for that information in a certain specific place, then doesn't it seem sensible to implement the unwritten "/favicon.ico API", and figure out which favicon to return?

To the argument about incurring an extra Drupal bootstrap: Many browsers (and websites/ web services) still in 2013 make requests for /favicon.ico in the root folder of a domain. This request often has nothing to do with a given page request, nor does it block the rendering of a normal page load, and therefore should be considered and treated as an independent individual server request, just like a request for /robots.txt. If you happen to have Drupal installed in a top level folder, then you are already incurring this extra Drupal bootstrap to log the 404 message. Thus, you lose nothing by implementing fallback logic in Drupal that can figure out what the appropriate favicon image should be, based on the requested URL..

The only real technical challenge to overcome is the fact that, in Drupal, favicon support is tied to themes not to the domain. Drupal promotes placing a favicon inside a theme folder instead of in the root of the site, for a variety of reasons including multi-site, and even just for the convenience of themers being able to package things together in one place. Furthermore, with the help of some contributed modules, it is technically possible to have a different theme and thus a different favicon on the homepage of your site, depending on anything from user role, geo location, language, browser, etc, etc.

I suppose since the favicon module already exists, and already implements this functionality (which currently requires a core hack to .htaccess) -- this is just a justification (and vote) for inclusion of favicon module in core.

klonos’s picture

Having the issue title be a proposed solution makes this sound like a feature request, but I honestly fail to see it that way. Hogging the log with the same message in every single page request seems like a perfectly valid bug that should be solved.

jwilson3’s picture

Title: Set good defaults to help browsers find favicon.ico files » Useless favicon.ico 404 messages in logs
Category: feature » bug

Per #88, how about a title like this, and a reclassification?

klonos’s picture

...much better indeed.

DanChadwick’s picture

Issue summary: View changes

I'm no apache expert, but #78 seemed to fail because Location directives can't be placed in .htaccess files. http://httpd.apache.org/docs/2.4/mod/core.html#location

An alternative would be to put the redirect directives in each vhost file. I plan to try this. This seems to be working in the vhost files:

  <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{THE_REQUEST} /favicon.ico [NC]
    RewriteRule ^ /sites/YOURDOMAIN.com/PATH/TO/ICON/ICONNAME.ico [R=301,L]
mgifford’s picture

Status: Needs work » Needs review
906 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch favicon404-174940-92.patch. Unable to apply patch. See the log in the details link for more information. View

This is an issue that's been open since 2007 that's still annoying folks. It looks bad when reviewing watchdog logs.

If the correct path is the one that @jwilson3 outlines in #87 is to continue to allow the 404's to appear in the apache log, but nix them from watchdog logs, then can we not just do something simple like add this exception within the on404Html function?

Status: Needs review » Needs work

The last submitted patch, 92: favicon404-174940-92.patch, failed testing.

DanChadwick’s picture

If the correct path is the one that @jwilson3 outlines in #87 is to continue to allow the 404's to appear in the apache log, but nix them from watchdog logs

I'm confused.
#87: Return the correct favicon by rolling the favicon module into core.
#92: Don't log favicon 404's in the watchdog log.

You can also do #91 in addition to either of the above, eliminating the bootstrap. It seems that the bugs that are nearly a decade old are ones where there are a bunch of pretty good solution and no core maintainer will just say "this one is good enough", commit, backport to D7 and close the issue. That should happen here.

jwilson3’s picture

But is #91 something you could actually put into core to solve this problem? Afaict that would still require developer or themer intervention to remember to edit the .htaccess file. If #91 were chosen, then we should *change the log message* to explain exactly what needs to be done to get rid of the message (or link to a doc page on d.o that explains what to do). Also, this doesn't help people who don't use Apache.

Seems far less invasive, and much more practical to leverage Drupal's 404 handler to test for this case, and provide a proper redirect.

DanChadwick’s picture

@jwilson3 -- I was just suggesting that a site maintainer -- following directions of some sort -- might set up their vhosts in order to avoid the bootstrap. This would be in ADDITION to the problem being "solved" in order as you or mgifford suggest.

I was not suggesting the core somehow edit vhosts files, or even create a log entry or status page entry. It could be part of the site building documentation and server setup instructions, however.

mgifford’s picture

Well, there were a bunch of problems with my patch in #92 but what happened to the ExceptionController.php & on404Html()? There are tests for it of course core/modules/system/src/Tests/Routing/ExceptionHandlingTest.php

Not sure what happened to this code that I swear that it was there 16 days ago.

tr-drupal’s picture

Hi all,

just finished a relaunch using Drupal 7 and see a lot of those favicon.ico message in the log. Went through this discussion now. Many suggestions, many pros and contras... Do I see it right, that the Favicon module is the way to go in order to solve this?

Anybody’s picture

I can confirm this problem sadly still exists and fills up watchdog... This really needs a D7 backport. How can we proceed after a lot of discussion here?

BTW: #48 works great for me but is not yet part of the .htaccess in D7.

izmeez’s picture

For D7 the favicon module http://drupal.org/project/favicon suggested in comment #81 seems to work well.

Anybody’s picture

Well you should not need a module for a clear bug which can be fixed with some htaccess lines from my point of view ;)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.