When (not)
to use .htaccess files
In general, you should only use .htaccess files when you do not have access to the primary server configuration file. There is, for example, a common misconception that user authentication should always be done on .htaccess files and, in more recent years, another misconception that mod_rewrite directives should go on .htaccess files. This is simply not the case. You can put user authentication settings in the main server configuration, and this is, in fact, the preferred way of doing things. Similarly, mod_rewrite policies work best, in many ways, in the main server configuration.
The .htaccess files should be used in a case where content providers need to make configuration changes to the server per directory, but do not have root access on the server system. In the event that the server administrator is unwilling to make frequent configuration changes, it might be desirable to allow individual users to make these changes to .htaccess files themselves. This is particularly true, for example, in cases where ISPs host multiple user sites on a single machine and want their users to be able to alter their settings.
However, in general, the use of .htaccess files should be avoided when possible. Any configuration you consider putting in an .htaccess file can be done just as effectively in a <Directory> section in your primary server configuration file.
There are two main reasons to avoid using .htaccess files.
The first of these is performance. When AllowOverride is configured to allow the use of .htaccess files, httpd will search each directory for .htaccess files. Therefore, allowing .htaccess files causes a performance impact, whether you use them or not! Additionally, the .htaccess file is loaded every time a document is requested.
Also, note that httpd must search for .htaccess files in all top-level directories, to have a full complement of policies to apply. (See how policies are applied.) Therefore, if a file is requested from a /www/htdocs/example directory, httpd must search
for the following files:
And so, for every file access outside that directory, there are 4 additional accesses to the file system, even if none of those files are present. (Note that this would only be the case if .htaccess files were enabled for /, which is not usually the case.)
In the case of RewriteRule directives, in the .htaccess context these regular expressions must be recompiled with each request to the directory, whereas in the primary server configuration context they are compiled once and cached. Also, the rules themselves are more complicated, as one must avoid the constraints that come with context and mod_rewrite per directory. See the Rewrite Guide for more details on this topic.
The second consideration is safety. You are allowing users to modify server settings, which can result in changes over which you have no control. Carefully consider whether you want to grant your users this privilege. Also note that giving users fewer privileges than they need will result in additional support requests. Be sure to clearly indicate to your users what level of privileges you have granted them. Specifying exactly what you’ve set AllowOverride on and directing them to the relevant documentation will save you a lot of confusion later on.
Note that it is completely equivalent to putting an .htaccess file in a /www/htdocs/example directory that contains a directive,
and putting that same directive in a directory section <Directory
“/www/htdocs/example”> in your server’s main configuration:
.htaccess in /www/htdocs/example:
However, putting these settings in your server’s configuration file will result in less performance impact, Since the configuration is loaded once when httpd is started, instead of every time a file is requested.
The use of .htaccess files can be completely disabled by setting the AllowOverride directive to none:
AllowOverride None
