Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
.htaccess contains
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
which effectively means that Apache won't run PHP and therefore no Drupal bootstrap happens. Apache handles the request itself. However, what that means is that Apache's own error log will be filled with entries about a missing 'favicon.ico' file. This is what gagarine mentioned in #174940-69: Useless favicon.ico 404 messages in logs and this has never been fixed.
Credit to a.ross in #121
Steps to reproduce
Proposed resolution
- Add a menu item for favicon.ico to return the theme's shortcut icon.
- Add 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.
Remaining tasks
>Patch
Review
Commit
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#92 | favicon404-174940-92.patch | 906 bytes | mgifford |
#78 | 174940-78-set-good-default-for-favicon.patch | 1.13 KB | gagarine |
#63 | htaccess-favicon-404-fix-174940-drupal5.patch | 1003 bytes | matt@antinomia |
#56 | htaccess-favicon-404-fix-174940_1.patch | 943 bytes | gpk |
#56 | htaccess-favicon-404-fix-174940_0_followup.patch | 762 bytes | gpk |
Comments
Comment #1
PasqualleI 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
Comment #2
webernet CreditAttribution: webernet commentedSome 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?
Comment #3
RobLoachThe 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.
Comment #4
webchickHm. 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.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedi don't mind shipping a blank icon in root and asking users to symlink the real one if they caare about these broken browsers.
Comment #6
zeta ζ CreditAttribution: zeta ζ commentedWhat 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.
Comment #7
dvessel CreditAttribution: dvessel commentedA 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.
Comment #8
webchickActually, 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.
Comment #9
markus_petrux CreditAttribution: markus_petrux commentedIMO, 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.
Comment #10
RobLoachComment #11
RobLoachMoving 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...
Comment #12
sparr CreditAttribution: sparr commented"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.
Comment #13
catchEven 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.
Comment #14
gpk CreditAttribution: gpk commentedre. #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>.)
Comment #15
markus_petrux CreditAttribution: markus_petrux commentedHaven'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...
Comment #16
Zach Harkey CreditAttribution: Zach Harkey commentedWhat about multi-site installations where the designer can't just replace the default blank /favicon.ico?
Comment #17
RobLoachReplacing an existing favicon.ico would also count as hacking core.
Comment #18
Zach Harkey CreditAttribution: Zach Harkey commentedOk, 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:
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.
Comment #19
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedsub
Comment #20
RobLoachThis 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.
Comment #21
RobLoachThanks, Zach. The attached patch does two things:
Comment #22
RobLoachMorbus 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.
Comment #23
alpritt CreditAttribution: alpritt commentedI'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.
Comment #24
gpk CreditAttribution: gpk commented>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.
Comment #25
alpritt CreditAttribution: alpritt commentedGood point. Therefore related to http://drupal.org/node/76824
Comment #26
davidwhthomas CreditAttribution: davidwhthomas commentedHere's the fixed .htaccess rewrite rule to prevent rewriting when the request is for the favicon itself
Alternatively, you can just copy your favicon.ico file to your drupal root.
DT
Comment #27
Dries CreditAttribution: Dries commentedA 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?
Comment #28
gpk CreditAttribution: gpk commented>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.Comment #29
moshe weitzman CreditAttribution: moshe weitzman commentedI'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.
Comment #30
gpk CreditAttribution: gpk commentedThat 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.
Comment #31
RobLoachWeb 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?
Comment #32
moshe weitzman CreditAttribution: moshe weitzman commentedSo 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.
Comment #33
RobLoachI 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...
Comment #34
Dries CreditAttribution: Dries commentedI 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.
Comment #35
gpk CreditAttribution: gpk commentedJust 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.
Comment #36
Pasquallemaybe 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?
Comment #37
Crell CreditAttribution: Crell commented@#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.
Comment #38
Dries CreditAttribution: Dries commented@#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.
Comment #39
alpritt CreditAttribution: alpritt commented@#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.)
Comment #40
Pasqualle@#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..
Comment #41
Dries CreditAttribution: Dries commented@#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.
Comment #42
gpk CreditAttribution: gpk commentedIsn'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).
Comment #43
Crell CreditAttribution: Crell commented"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.
Comment #44
RobLoachGreat summary, gpk. I'd have no problem maintaining that 10 line contrib module :-P .
Comment #45
gpk CreditAttribution: gpk commented@#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!
Comment #46
Dries CreditAttribution: Dries commentedExcellent analysis.
Based on the analysis, I now vote that we fill up the accesslog with 404s. It's better than an empty favicon, IMO.
Comment #47
mcurry CreditAttribution: mcurry commentedsub
Comment #48
gpk CreditAttribution: gpk commentedYeah, 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
add
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:
insert another RewriteCond immediately after the existing 2 (and above the RewriteRule):
(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 ...
Comment #49
Dries CreditAttribution: Dries commentedgpk (or somoene else), would you mind rolling a patch for the proposal in #48? I'd be happy to commit that to CVS HEAD.
Comment #50
gpk CreditAttribution: gpk commentedOK...
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.Comment #51
gpk CreditAttribution: gpk commentedActually 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.
Comment #52
gpk CreditAttribution: gpk commentedActually 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.
Comment #53
Dries CreditAttribution: Dries commentedI 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.
Comment #54
RobLoachIs it just me, or is there an extra quote at the end?
http://www.buytaert.net/favicon.ico
Comment #55
xmacinfoI vote to see this in Drupal 5 as well.
Comment #56
gpk CreditAttribution: gpk commented@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.
Comment #57
Dries CreditAttribution: Dries commentedCommitted #56 to CVS HEAD. Should probably go into DRUPAL-6 as well.
Comment #58
Gábor HojtsyThanks, committed #56 to Drupal 6 as well.
Comment #59
gpk CreditAttribution: gpk commentedPer #55. I've not checked if the _1 patch at #56 applies to D5 or not.
Comment #60
RobLoachI've put together the contrib module that adds the menu item..... http://drupal.org/project/favicon
Comment #61
EoinBailey CreditAttribution: EoinBailey commentedI tried this module, gave me the WSOD.
Comment #62
gpk CreditAttribution: gpk commented@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.
Comment #63
matt@antinomia CreditAttribution: matt@antinomia commentedPatch for D5 attached. Those favicon 404s are driving me crazy!
Comment #64
slosa CreditAttribution: slosa commentedsubscribing
Comment #65
hedac CreditAttribution: hedac commentedI'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?
Comment #66
RobLoachfavicon.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.
Comment #67
drummCommitted to 5.x.
Comment #69
gagarine CreditAttribution: gagarine commentedD6.22 and full of those line in /var/log/apache2/error.log
Comment #70
gpk CreditAttribution: gpk commentedYes 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.
Comment #71
geerlingguy CreditAttribution: geerlingguy commented@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 :-/
Comment #72
dynamicdan CreditAttribution: dynamicdan commentedVoting 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.
Comment #73
dynamicdan CreditAttribution: dynamicdan commentedNote: not making a new issue because the history/solutions are here.... somewhere.
Comment #75
RobLoachYeah, I've just been ignoring the warnings. Would be nice if they went away though......
But, 8.x first, then 7.x ;-) .
Comment #76
gagarine CreditAttribution: gagarine commentedA 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...
Comment #77
cweagansUpdating tags per http://drupal.org/node/1517250
Comment #78
gagarine CreditAttribution: gagarine commentedHere a patch. What do you think?
Comment #80
David Lesieur CreditAttribution: David Lesieur commentedMarked #1588820: Drupal handles 404 for /favicon.ico as duplicate.
Comment #81
gpk CreditAttribution: gpk commented@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.
Comment #82
RobLoachhttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#r...
Assuming /favicon.ico seems like a hack when we could use rel=icon and hook_html_head_alter().
Comment #83
cweagans#82 is what we should do to properly support multisite.
Comment #84
gagarine CreditAttribution: gagarine commentedBecause 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.
Comment #85
gpk CreditAttribution: gpk commented>Do you speak about the code in comment?
Yes!
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.
Comment #86
candelas CreditAttribution: candelas commentedgetting this warning in drupal 7.22
thanks for your work :)
Comment #87
jwilson3As 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.
Comment #88
klonosHaving 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.
Comment #89
jwilson3Per #88, how about a title like this, and a reclassification?
Comment #90
klonos...much better indeed.
Comment #91
DanChadwick CreditAttribution: DanChadwick commentedI'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:Comment #92
mgiffordThis 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?
Comment #94
DanChadwick CreditAttribution: DanChadwick commentedI'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.
Comment #95
jwilson3But 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.
Comment #96
DanChadwick CreditAttribution: DanChadwick commented@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.
Comment #97
mgiffordWell, 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.
Comment #98
tr-drupal CreditAttribution: tr-drupal commentedHi 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?
Comment #99
AnybodyI 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.
Comment #100
izmeez CreditAttribution: izmeez commentedFor D7 the favicon module http://drupal.org/project/favicon suggested in comment #81 seems to work well.
Comment #101
AnybodyWell you should not need a module for a clear bug which can be fixed with some htaccess lines from my point of view ;)
Comment #114
xmacinfoWhat is happening with this issue? I see multiple commits.
Comment #115
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commented@xmacinfo - Yeah, I'm seeing this across a huge number of issues in my feed, see: https://twitter.com/geerlingguy/status/1241114270655557636 — no clue what's going on.
Comment #116
a.ross CreditAttribution: a.ross commentedI've used this in the past: https://gist.github.com/ameenross/2cc35daa45b5b3e2fe840ddcce95523b
Clearly also lean towards "lie". C'mon, it's a dinosaur.
Comment #117
jwilson3Seriously? So many questions about that ^. First of all is how could that really be a good idea to troll browsers in this way (serving plain text for a file requested with an .ico extension)? Secondly if you're going to go out of your way to serve a response, why not just serve the site's favicon.ico, or if you didnt create one, serve the default drupal favicon with a simple copy/paste.
Comment #118
a.ross CreditAttribution: a.ross commentedThe extension doesn't really have any meaning at all, although the
Accept
header does. Also, usingexample.com/favicon.ico
has been discouraged for over a decade, and the proper way to do it has existed for more than 2 decades. The fact that webmasters have been lazy and received bad advice on forums during this time period is the only reason that browser vendors are fearful to remove the "feature" in its entirety.But those requests result in bootstrapping the entire application, wasting a lot of resources for no benefit and logging a totally uninteresting 404 in Drupal's DB log. If a webmaster copies the favicon to
example.com/favicon.ico
that's their business, but I don't think that Drupal itself should go out of its way to serve the configured favicon for requests toexample.com/favicon.ico
. It's way too many CPU cycles for no benefit whatsoever, as every conceivable theme uses an HTML rel tag for it (and browsers comply — it's not even listed on CanIUse).Again, it's 2020 and we're talking about a dinosaur.
Comment #120
quietone CreditAttribution: quietone as a volunteer commentedTo summarize this issue:
This issue was committed to Drupal 7.x, see #57, and Drupal 6.x, see #58, and stayed open for a port to Drupal 5, see #59. It was committed to Drupal 5, see #67
The reopened for errors in D 6.22 #69 and moved along in version until now it is against 8.9.
This is marked needs works but it is tough to figure out what what that work is. The latest comments, from March 2020 onwards, suggest this is no longer an issue. Is this still an issue?
Changing to NR to decide what needs to be done.
Comment #121
a.ross CreditAttribution: a.ross commentedSorry my comments might have been noise.
It looks like the solution has been to add favicon to the .htaccess rewrite rules like this:
This effectively means that Apache won't run PHP and therefore no Drupal bootstrap happens. Apache handles the request itself. However, what that means is that Apache's own error log will be filled with entries about a missing 'favicon.ico' file. This is what gagarine mentioned in #174940-69: Root /favicon.ico accounts for majority of 'Page not found' errors and this has never been fixed.
Comment #122
quietone CreditAttribution: quietone as a volunteer commented@a.ross. Thanks. Updated the IS
Comment #123
quietone CreditAttribution: quietone as a volunteer commentedComment #124
larowlanThis issue talks about IE6 and IE7 - does this issue still occur now those browsers are long gone
Comment #125
larowlanFor above and because there's no patch
Comment #126
larowlanActually, given this is separate issue to what was committed, should we mark this fixed and open a new issue
Comment #127
quietone CreditAttribution: quietone as a volunteer commentedOK. let's do that. It will be a lot easier to work on then.
I have updated the proposed resolution with what was done in Drupal 6. And changed the title back to what is was at the time of the commit.
Created #3220939: Apache log can fill with 404 favicon.ico missing messages
Comment #129
ressa CreditAttribution: ressa at Ardea commentedMy Drupal 7 logs were getting filled with "page not found" entries looking for a root favicon file at https://example.org/favicon.ico. I thought this issue was fixed by default in Drupal 7, but I had to enable
drupal_fast_404();
in settings.php and now these requests are not getting logged, great.