Why you should not use .htaccess (AllowOverride All) in production


Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server’s behavior without modifying the configuration file or restarting the server.  Personally, I think this is great for development purposes.  It allows you to quickly test various server configurations without needing to mess with restarting the server.  It helps you be more (buzzword alert!) agile.

Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact.  What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

To demonstrate this I used a program called strace which checks for system calls and gives you a list of each system call that is made.

First we’ll take a look at the strace with AllowOverride set to None.

Now let’s take a look at the strace results with AllowOverride set to All.

You can clearly see the additional open() calls being made to try and discover the .htaccess file.  In this case the calls are completely superfluous because we have nothing there.  But even so we have a significant impact on static file throughput.

AllowOverride None

AllowOverride All

The requests where AllowOverride was turned off were executed at 60% of the time of the ones where AllowOverride was turned on.

And remember, this is just the impact of file operations and does not take into account the time to reconfigure Apache during the course of these requests.

So the data would clearly show that there is a negative impact to having AllowOverride turned on in a production environment.  Instead it will generally be better to take those changes in .htaccess and place them in your httpd configuration file.


In fact Mike Willbanks says you should never do it.  I  agree with him, but I wouldn’t make as big a stink in dev as I would in prod.


16 thoughts on “Why you should not use .htaccess (AllowOverride All) in production

  1. It is okay to have one in your root folder and there set it to none right? Or do you want to put all the alias/ expires/ rewrite stuff in the vhost? o.0 At least give us an alternative.

      1. Thanks for your reply, but my system manager tells me otherwise. He tells me to put everything per site in a .htaccess instead the httpd.conf. We have like over 250+ vhosts. In this situation, is it still prefered to put everything in httpd.conf?

        1. If throughput is a concern. As we saw in the benchmark, disabling AllowOverride caused a 40% improvement in performance for static files. There is also the inherent security issue of allowing items in your document root change the configuration of your web server on the fly.

  2. Kevin, thanks for your investigation of this important server config option. As an admin of a shared vhost with no access to httpd.conf, I use .htaccess to blacklist bothersome visitors. Can you think of an alternate to .htaccess that offers better performance?

    1. If you have no access to httpd.conf then your options are pretty limited. That said, I don’t know what your requirements are for running a shared host, but I have the cheapest Linode VM which gives me full access for $20 a month and I love it.

  3. There’s 2 other Apache options that have the same effect : FollowSymlinks and its friend SymLinksIfOwnerMatch. Unless you know there are symbolic links in your document root path somewhere, disabling them is a good idea.

      1. I tested it more than 2 years ago, in preparation for my Caching & Tuning tutorial at phpBenelux and it made anywhere between 20-40% difference. Haven’t tested it since though.

  4. If you have an application where the bottleneck is a 1.5 second delay across 10,000 requests (0.00015/request) handled by apache, I applaude your optimisation skills.

  5. cags You have misread the log. It says the concurrency level was 10, so that many concurrent requests were served at the same time at most. 10000 was merely the total sum of requests performed to reduce the impact of random server hiccups I guess.

Leave a Reply

Your email address will not be published. Required fields are marked *