.htaccess Configuration
Because .htaccess is stored in the webroot of a site/application, it has the following advantages and disadvantages when deploying rewrite rules:
.htaccess Advantages
- Easy to keep it under version control
- Easy to include as part of a deployment package
- Easy to create rewrite rules independent of the target server’s OS or existing configuration
- Does not require restarting the Apache httpd server to pick up changes
.htaccess Disadvantages
- .htaccess files are read on every request; i.e., every request to the server causes Apache to look in the current directory for an .htaccess file and if it does not find one, it will then look in the parent directory for one, and so on up to the webroot
- Any rules that may apply globally to all sites on the server must be replicated in each site’s .htaccess file
Per the Apache docs, you should only use .htaccess files when you don’t have access to the server configuration. And while a case can be made for distributed configuration files like .htaccess, generally any configuration you would have in them can just as effectively be made in one of the server’s main configuration files.
Virtual Host Configuration
Putting rewrite rules into vhost configuration instead of .htaccess has the following advantages and disadvantages:
Virtual Host Config Advantages
- Performance benefits due to config files being read during server initialization and not having to be re-evaluated on a per-request basis like .htaccess
- Allows consolidation of rules at the server level
- Allows ‘global’ rules to be created which affect more than one site
Virtual Host Config Disadvantages
- Not being able to put rules under version control at the per-site level as can be done with .htaccess
- Not being able to include rules in deployment packages in a simple fashion
- Requires restarting the Apache httpd server to pick up changes
- Requires access to the server’s configuration files (not that this is a disadvantage per se, it’s more of just being requirement)
It’s easy to create rules that globally affect all or many sites; e.g. to prevent access to certain files such as wp-config.php, which you would want to do for all WordPress sites that may be configured on a server.
.htaccess Example
In the following case, an example of a default WordPress setup:
[sourcecode language="xml"]RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] [/sourcecode]
Virtual Host Configuration Example
Serves the same purpose as in the .htaccess example:
[sourcecode language="xml"]ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/html/example.com # turn off .htaccess in root [/sourcecode]Options -Indexes +FollowSymLinks AllowOverride None # WordPress configurationRewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]