Redirect All Requests for a Nonexistent File to the Actual File

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://example.com/wp/favicon.ico
• http://example.com/press/2007/06/12/favicon.ico
• http://example.com/absolute-horizontal-and-vertical-centering-via-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:

1. Check for the required Apache module, mod_rewrite
2. Enable rewriting by activating the RewriteEngine
3. Check if the requested URI is the actual file
4. Match any nonexistent URI that contains the target file
5. Redirect any matching URI to the actual file
6. 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 the Author

Jeff Starr = Creative thinker. Passionate about free and open Web.