Weird File Requests and Easing Server Stress with .htaccess

Avatar of Chris Coyier
Chris Coyier on (Updated on )

I got an email from Media Temple (my hosting provider for CSS-Tricks) telling me that I was going to exceed my “GPU” limit for the month. Wha? Turns out a GPU is a “Grid Performance Unit” and is a Media Temple specific way to calculate how much server resources you are using. I think everything but database stuff is included in this. They provide a “GPU Tool” as part of their interface to show you what parts of your website are causing the most usage. I figured I’d better check it out to make sure everything was normal.

The top three usages for this site are the homepage, the RSS feed, and the Atom feed. Makes sense to me… but the fourth on the list stuck out. It was the url “css-tricks.com/images/ajax-loader.gif”. Check it out:

I don’t really use any AJAX on this site, save for a little simple jQuery stuff. My first thought was the poll as that has had some weird issues in the past and does indeed use a little spinner thing to show results. But that wasn’t it… different file name. What’s weird is that the file doesn’t exist, which is why it was throwing a 404 error when accessed.

Now when you have WordPress (or some other CMS) installed on your site, chances are you have a 404 page that is built into that, to provide a bit more user-friendly experience than a blank white browser default error page. Check out my 404 page. OK, so it could be a bit more user-friendly but that’s another story. The point is, it takes the server a heck of a lot more resources to cough up that whole page then it would to serve up a little GIF image. I found a spinning GIF image I had laying around with that name and threw it in my images directory.

  • Total size of 404 page: 767 KB
  • Total size of ajax-loader.gif: 4 KB

So where are these weird requests coming from? I’m 99% sure they are something random and possibly malicious and not coming from legitimate request from this site. What I do know, is that I can save myself 763 KB of bandwidth/resources on every single request for this file if I just serve up the image and not the 404 page. When it’s getting hit over 16,000 times a month, that adds up!

But this wasn’t the only URL that was getting hit for requests for this weird file! All kinds of URL’s were getting hit with it, all css-tricks.com URL’s. Mostly differerent random posts, like “css-tricks.com/random-post-title/images/ajax-loader.gif”. All added up, these random ones were even more stressful than the main one in /images.

I needed a catch-all solution to re-direct all these weird requests to get to the right place. As luck would have it, Jeff Starr over at Perishable Press had written a timely article about a similar problem he was having: Redirect All Requests for a Nonexistent File to the Actual File. His problem was originally for weird requests to non-existent favicon.ico files. I was seeing a bit of that as well, and also some robots.txt requests.

Time to stop all this madness and fix this!

With some .htaccess voodoo, I was able to get ANY request for this “ajax-loader.gif” file, as well as favicon.ico files to redirect to their ACTUAL locations on the the server and stop throwing bandwidth-sucking 404 errors.

Here is the final code:

# REDIRECT FAVICON.ICO
<ifmodule mod_rewrite.c>
RewriteCond %{REQUEST_URI} !^/favicon\.ico [NC]
RewriteCond %{REQUEST_URI} favicon\.ico    [NC]
RewriteRule (.*) https://css-tricks.com/favicon.ico [R=301,L]
</ifmodule>

# REDIRECT AJAX-LOADER
<ifmodule mod_rewrite.c>
RewriteCond %{REQUEST_URI} !^/images/ajax\-loader\.gif [NC]
RewriteCond %{REQUEST_URI} ajax\-loader\.gif           [NC]
RewriteRule (.*) https://css-tricks.com/images/ajax-loader.gif [R=301,L]
</ifmodule>

HUGE thanks to Jeff Starr for working with me on this and getting it working properly. You can see it in action by trying to request the file like this:

https://css-tricks.com/blahblahblah/ajax-loader.gif

You will get instantly re-directed to the proper location.

Note: If you are using WordPress and have special perma-links (like I do), there is a chunk of WordPress-specific stuff already in your root-level .htaccess file. This stuff needs to go BEFORE that to work right.