Root /favicon.ico accounts for majority of 'Page not found' errors
sparr - September 12, 2007 - 05:54
| Project: | Drupal |
| Version: | 5.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
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.
#1
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
#2
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?
#3
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.
#4
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.
#5
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.
#6
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.
#7
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.
#8
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.
#9
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.
#10
#11
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...
#12
"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.
#13
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.
#14
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>.)
#15
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...
#16
What about multi-site installations where the designer can't just replace the default blank /favicon.ico?
#17
Replacing an existing favicon.ico would also count as hacking core.
#18
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
Pros:
- 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)
Cons:
- 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.
#19
sub
#20
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.
#21
Thanks, Zach. The attached patch does two things:
#22
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.
#23
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.
#24
>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.
#25
Good point. Therefore related to http://drupal.org/node/76824
#26
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 itselfRewriteCond %{REQUEST_URI} !^/favicon.ico$
RewriteRule favicon.ico$ /favicon.ico [NC,L]
Alternatively, you can just copy your favicon.ico file to your drupal root.
DT
#27
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?
#28
>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.#29
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.
#30
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.
#31
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...
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?
#32
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.
#33
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...
#34
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.
#35
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.
#36
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?
#37
@#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.
#38
@#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.
#39
@#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.)
#40
@#39
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..
#41
@#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.
#42
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).
#43
"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.
#44
Great summary, gpk. I'd have no problem maintaining that 10 line contrib module :-P .
#45
@#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!
#46
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.
#47
sub
#48
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
add
# 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."
</Files>
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 ...
#49
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.
#50
OK...
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.#51
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.
#52
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.
#53
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.
#54
Is it just me, or is there an extra quote at the end?
http://www.buytaert.net/favicon.ico
#55
I vote to see this in Drupal 5 as well.
#56
@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.
#57
Committed #56 to CVS HEAD. Should probably go into DRUPAL-6 as well.
#58
Thanks, committed #56 to Drupal 6 as well.
#59
Per #55. I've not checked if the _1 patch at #56 applies to D5 or not.
#60
I've put together the contrib module that adds the menu item..... http://drupal.org/project/favicon
#61
I tried this module, gave me the WSOD.
#62
@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.
#63
Patch for D5 attached. Those favicon 404s are driving me crazy!
#64
subscribing
#65
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?
#66
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.
#67
Committed to 5.x.
#68
Automatically closed -- issue fixed for 2 weeks with no activity.