Redirect All Requests for a Nonexistent File to the Actual File
Published Tuesday, August 12, 2008 @ 11:47 pm • 19 Responses
In my previous article on redirecting 404 requests for favicon files, I presented an HTAccess technique for redirecting all requests for nonexistent favicon.ico files to the actual file located in the site’s web-accessible root directory:
# REDIRECT FAVICONZ
<ifmodule mod_rewrite.c>
RewriteCond %{THE_REQUEST} favicon.ico [NC]
RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L]
</ifmodule>As discussed in the article, this code is already in effect here at Perishable Press, as may be seen by clicking on any of the following links:
- http://perishablepress.com/press/favicon.ico
- http://perishablepress.com/press/2007/06/12/favicon.ico
- http://perishablepress.com/press/2007/09/25/absolute…css/favicon.ico
Clearly, none of these URL requests target the “real” favicon.ico file, yet thanks to the previous method they are all happily redirected to the proper location. This is useful for a variety of reasons, including preventing excessive and unnecessary server strain due to malicious scripts.
Shortly after posting this method, Chris Coyier of CSS Tricks discovered that the code was causing an infinite redirection loop when applied to his site. After some experimentation, I have resolved the infinite loop issue, improved the syntax, and adapted the code to work from virtually any location.
The previous favicon redirection method works as advertised, but only if placed in a subdirectory, such as would be the case for WordPress installations located in their own non-root directory. For example, this WordPress installation for Perishable Press is located in a subdirectory named “press”. Within the HTAccess for the press subdirectory, the first version of this redirection technique works perfectly. When placed in the root directory, however, the code fails by creating the infinite loop. Thus, a better solution is needed..
Universal Redirect for Nonexistent Files
The following technique works in any directory — subdirectory or site root:
# REDIRECT 404 FILES
<ifmodule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/favicon\.ico [NC]
RewriteCond %{REQUEST_URI} favicon\.ico [NC]
RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L]
</ifmodule>To implement this technique, replace both instances of “favicon.ico” with any file that you would like to redirect. The favicon is a good a choice for reasons discussed in the previous article, but other good candidates would be your site’s robots.txt file or any other file that seems impossible for people and bots to find. Further, if the location of the “real” file is located somewhere other than the root directory, indicate such in the first RewriteCond (e.g., !^/images/favicon\.ico). Then, after the rewrite conditions are taken care of, edit the RewriteRule to reflect the full URL of the actual file.
A couple of notes.. First, it is recommended that you place this code as far up the directory structure as possible. Begin with the site root HTAccess file. In most configurations, that should work fine; however, in some cases, such as when WordPress is installed in a subdirectory but is serving permalinks written without the subdirectory showing in the URL, the redirect may simply not happen. If this is the case, or if the redirect does not occur for some other reason (conflicting rewrite rules, etc.), try placing the code in the subdirectory. Bottom line: place the code in the root HTAccess and if the redirects don’t kick in, place the code in the blog subdirectory. The good news here, and the main reason for this improved method, is that the code will no longer trigger an infinite loop and crash your site; it is much safer, much cleaner, and more widely applicable.
Having bored you to tears with all of that detail, allow me to deliver the death blow with an explanation as to what’s actually happening when this code is executed. I think a nice, numbered list will help simplify the process:
- Check for the required Apache module,
mod_rewrite - Enable rewriting by activating the
RewriteEngine - Check if the requested URI is the actual file
- Match any nonexistent URI that contains the target file
- Redirect any matching URI to the actual file
- Close the module check container
Conclusion
Hopefully, this technique will be useful for anyone needing to stop those relentless 404 requests for nonexistent files. Doing so will not only help increase the effectiveness of your error-log investigations, but also help reduce the unwanted server load associated with automated directory prowling via arbitrary file candidates. Or something ;)
About this article
Related articles
- Stop the Madness: Redirect those Ridiculous Favicon 404 Requests
- htaccess Combo Pack: WordPress Permalinks and non-www Redirect
- Redirect any Subordinate URL to its Parent Directory via PHP
- Redirect All (Broken) Links from any Domain via HTAccess
- Permanently Redirect a Specific IP Request for a Single Page via htaccess
- Redirecting Subdirectories to the Root Directory via HTAccess
- Redirect WordPress Individual Category Feeds to Feedburner via HTAccess
Dialogue
19 Responses Jump to comment form
August 14, 2008 at 1:08 pm
I am pretty new to this, exactly where do I put the script. Is in the htaccess file?
August 24, 2008 at 3:15 pm
Great Work Perishable
I’ve customised your code to meet my specific reqs, namely to protect against hotlinkers linking directly to my content.
RewriteCond %{HTTP_REFERER} xx\.xxxxx\.com [NC,OR]
RewriteCond %{HTTP_REFERER} xxxxx\.org [NC]
RewriteRule \.(swf)$ redirect.swf [NC,L]
If you were in the UK I’d buy you a beer.
September 11, 2008 at 7:37 pm
I was looking for this rewrite code for Wordpress for quite awhile, couldn’t get it to work myself. Thanks!
September 17, 2008 at 3:46 pm
Hello,
I am having some trouble redirecting URL on my site. I used Expression Engine to mount it, and suddenly something happened and this kind of redirectioning are not working anymore:
http://loscuchillos.com/letras should go to http://loscuchillos.com/index.php/letras
So, what I basically need to perform is an automatic redirection to /index.php/NAME of whatever NAME typed as a subfolder. Without showing the whole address.
So the code the Expression Engine provides to get this kind of redirectioning (http://expressionengine.com/wiki/Remove_index.php_From_URLs/) is not working anymore.
It was working before and now I wounder what could be wrong.
Rewrite Module is enabled, same as .httaccess
Is there anythins else I should consider?
I’d really appreciate any comments on this issue.
Thanks,
Piller
September 28, 2008 at 12:32 am
Hello,
Be careful with the redirection, you can have an infinite loop.
To avoid that, you can rename the favicon.ico file by something else.
Eg :
RewriteCond %{THE_REQUEST} favicon.ico [NC]
RewriteRule (.*) /favicon_all.ico [R=301,L]
If I don’t do this, I get infinite redirections…
September 28, 2008 at 7:27 pm
Hello Jeff Starr,
My apologies, you are right, I didn’t read the whole article and just copy-pasted blindly the code… Now that works much better with the new code ;)
Have a nice day.
December 20, 2008 at 6:17 am
Hi Jeff,
First of all, you have a great site.
I too get tons of 404s with favicon.ico missing like your example post URLs from your site shown above. I followed your steps and read several times to get this correct. For some reason, the redirect does not happen at all. Let me explain further on my site configuration.
I have the main site in the root directory which is not blog (plain static site). In the sub-directory I have a blog with it’s own domain name. So I have a .htaccess file specifc to my blog in this sub-directory. Currently that’s where I have all rewrite commands. So I added your rewrite commands to this file towards the bottom. Still I get 404s for favicon.ico & .gif files.
What am I missing?
Thanks for your help.
December 20, 2008 at 6:41 am
Ok. I found the problem.
The set of lines that you suggested to be in put in .htaccess file should go all the way to the top of the file - only then it kicks in. Otherwise it has been ignored.
Thanks.
December 29, 2008 at 2:48 am
I just discovered all these favicon 404’s after installing CyStats. Rather annoying. Thanks for the code, it seems to help. But what ARE all these 404’s? Who or what is looking for my favicon in all possible places, and above all - why??
Trackbacks / Pingbacks
Share your thoughts..
← Previous post • Next post →
« Stop the Madness: Redirect those Ridiculous Favicon 404 Requests • Yahoo! Once Again Caught Disobeying Robots.txt Rules »
1 • Louis
August 13, 2008 at 2:21 am
I wonder if it’s a good idea to redirect the request to the favicon. That won’t make the automatic requests stop, and that will burn some bandwidth that would not have been burned if you just ignore the request.
My point would be that your idea is cleaner, but will waste ressources :/