3 Reasons not to use Apache mod rewrite

After reading this discussion on Slashdot regarding an anti-virus agent pretending to be Internet Explorer and flooding sites with requests I waited to see a response come from an Apache fan on using mod_rewrite to detect and stop the flood of useless traffic coming from these robots. It was sure to come, particularly after the first post in the discussion pointed out how to use an iRule to detect and "nuke from orbit" these nasty little requests. I was not disappointed.

It's not the case that the solution won't work. It will, and it's certainly a viable solution. At least if you're only running 2 or 3 web servers. And you don't care about the need to interrupt service to implement the solution. And you aren't worried about potentially introducing errors into the server configuration. And you're aren't running IIS or some other web server.

There are a few very good reasons not to use Apache mod_rewrite for this kind of situation.

1. It's less efficient.
   mod_rewrite requires that the server respond to the useless request, which means it's chewing up valuable resources on the server and the network that could be used to handle legitimate requests. Using mod_rewrite gains very little when you're attempting to stop useless traffic and requests from overloading your network or web servers because the traffic has to reach the servers and the web servers have to respond.
   
   Not only is it less efficient in terms of computing resources, but it's less efficient for administrators to develop, test, and deploy the solution on every server. That takes time, time that could certainly be spent doing other administrative tasks.
   
   By implementing the same "detect and nuke" functionality on the load-balancer (application delivery controller) you (a) prevent the traffic from flooding your network, (b) conserve resources on the server that can be used to serve legitimate requests, and (c) can implement the solution much faster as it only needs to be implemented once rather than once per server.
2. It only works in homogeneous environments.
   If you're running all Apache web servers, great. But very few environments are standardized on a single web server platform.
   
   By implementing the same "detect and nuke" functionality on the load-balancer (application delivery controller) you can prevent the consumption of resources on all web server platforms at the same time without needing to implement 2,3, or more different solutions on the web servers.
3. It requires an interruption to services.  
   In order to deploy a mod_rewrite solution the Apache configuration file must be modified and Apache restarted. That means all connected clients will have their service interrupted, and if there's an error or some other problem with the configuration it will result in down time. Either administrators need to quiesce (bleed) the connections off before restarting, or they need to simply hit the reset button without concern for connected clients. Depending on the services running on the affected server, that can be bad news for business.
   
   By implementing the same "detect and nuke" functionality on the load-balancer (application delivery controller) you won't need to restart the web servers nor interrupt service. Because the load-balancer is managing the connections and handling the inspection of requests, the servers don't need to be restarted and connection management can be handled by the application delivery controller.

So basically, if you're running a small, homogenous server farm and don't care about downtime/interruptions to service then using Apache mod_rewrite to solve this - or a similar - problem then go ahead and use mod_rewrite. But if you're in charge of a lot more servers, and it's a heterogeneous environment, and you can't interrupt service then you should be seriously considering implementing this kind of functionality in your application delivery controller instead.

Once again, just because you can, doesn't mean you should.