Apache Directives in Config vs .htaccess
Apache, Sysadmin
Apache allows configuration rules to be overridden at the directory level by means of distributed configuration files. These files are usually called .htaccess
, but the file name can be customised. Directives placed in .htaccess
apply to the directory that contains the file, and changes to .htaccess
have immediate effect for that directory. However, this can be wasteful of resources - .htaccess
files are read on every request.
In general, you should only use .htaccess files when you don’t have access to the main server configuration file…
….htaccess files should be used in a case where the content providers need to make configuration changes to the server on a per-directory basis, but do not have root access on the server system…
…However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a
section in your main server configuration file.
If you’re managing sites on a VPS, there’s no need to use distributed configuration files. I think I personally became conditioned to them from managing sites on shared hosting, with no root access.
Because of this, I’ve been moving Apache rewrite rules and access restrictions out of .htaccess
files and into virtual host configs.
Global Rules
In some cases, the rules that might have gone into a .htaccess
file can be applied at a server level - for example, preventing access to .git
directories and restricting access to config files (e.g. wp-config.php
) is probably best achieved by adding appropriate rules to /etc/apache2/conf-enabled/security.conf
(the Ubuntu apache2 security config file). If you’re blocking access to these files in one directory, the chances are that you’ll want to apply this to the whole server.
Per-Directory Rules: WordPress
The normal WordPress rewrite block can be easily added to a virtual host config. This allows you to disallow overriding at the directory level which speeds things up.
The following sections contrast how to achieve the same effect with a .htaccess
file and a virtual host configuration. In this case, a set of WordPress rewrites are needed, along with some restrictions based on IP address.
Typical WordPress .htaccess File: Production Site
The .htaccess
file is placed in the site document root. If the file is writeable by WordPress, WP will generate the config block between # BEGIN WordPress
and # END WordPress
.
The following .htaccess
file has an additional rule that restricts access to the main site login by IP.
Apache vHost Configuration with WordPress Specific Rules
To achieve the same thing without use of .htaccess
, amend the site virtual host config file:
Typical .htaccess Rules for Private Staging Site
This .htaccess
file is for a site that is in a sub-directory of the domain document root. For example: testdomain.com/testsite
. This is often a convenient way of handling staging websites.
In this case, the main Apache vHost configuration for the “parent” domain needs to allow override by means of .htaccess
. This is achieved by setting the AllowOverride
directive to “All” in the virtual host config file. When this directive is set to None and AllowOverrideList is set to None, .htaccess
files are completely ignored. In this case, the server will not even attempt to read .htaccess
files in the filesystem.
Reload Apache Configs
If you move your local config into virtual host configs, any changes you make will not take effect until you reload Apache:
comments powered by Disqus