Move Apache2 .HTACCESS Redirects to HTTP.D

After performing a performance analysis on one of our client’s enterprise magento websites, we noticed that their .HTACCESS file was very large compared to what we typically see.

Upon closer examination we noticed that there were more than 400+ redirects and re-writes that had been carried over from their previous ecommerce shopping cart systems.

Based on Apache’s documentation (http://httpd.apache.org/docs/2.2/howto/htaccess.html), they recommend only using .htaccess files when you do not have access to the main server file.

This is because it will cause a performance hit as the file is loaded every time a document is requested. So we setout to migrate the files as painlessly as possible to their "sites-enabled" main virtual host file, that would only be loaded once when the server was started. First thing was first, we removed all of the redirect and rewriterules from the main .htaccess file and made sure it worked properly. We left the native magento rules in place. Secondly, we created a new file called "client_redirects" and put it in the /etc/apache2/ folder. We put all of our original redirects/rewrites into this fle. Secondly, we linked to this file from the vhost file of the main site profile. Right above the very last </Directory> tag we added: Include /etc/apache2/client_redirects (Make sure your path matches up!). Seems easy enough right? Wrong. <strong> There is One VERY large difference!</strong> In this new redirect file you cannot use the "RewriteBase /" option. You instead HAVE to change all of your rewrite rules to be absolute paths, based on your webserver. For example, the previous rule in the .HTACCESS file could be <pre> RewriteRule my-feed.xml my-feed.php [L] </pre> In our new master file, you need to change it to be: <pre> RewriteRule ^/my-feed.xml /my-feed.php [L] </pre> Note the carrot and front slash required for the proper path. All of your RewriteRules will need to be replaced like this. A quick search/replace usually works pretty well. After all is said and done, you need to test your configuration file using the "apachectl" command. <pre> apachectl configtest </pre> Note and correct all/any errors. When you are all set, perform a graceful apache restart. <pre> apachectl graceful </pre> Make sure you spot check your rules in a browser to ensure they are working.”>http://httpd.apache.org/docs/2.2/howto/htaccess.html), they recommend only using .htaccess files when you do not have access to the main server file. This is because it will cause a performance hit as the file is loaded every time a document is requested.

So we setout to migrate the files as painlessly as possible to their “sites-enabled” main virtual host file, that would only be loaded once when the server was started.

First thing was first, we removed all of the redirect and rewriterules from the main .htaccess file and made sure it worked properly. We left the native magento rules in place.

Secondly, we created a new file called “client_redirects” and put it in the /etc/apache2/ folder. We put all of our original redirects/rewrites into this fle.

Secondly, we linked to this file from the vhost file of the main site profile. Right above the very last tag we added:
Include /etc/apache2/client_redirects
(Make sure your path matches up!).

Seems easy enough right? Wrong.

There is One VERY large difference!

In this new redirect file you cannot use the “RewriteBase /” option. You instead HAVE to change all of your rewrite rules to be absolute paths, based on your webserver.

For example, the previous rule in the .HTACCESS file could be

	RewriteRule my-feed.xml my-feed.php [L]

In our new master file, you need to change it to be:

	RewriteRule ^/my-feed.xml /my-feed.php [L]

Note the carrot and front slash required for the proper path.

All of your RewriteRules will need to be replaced like this.  A quick search/replace usually works pretty well.

After all is said and done, you need to test your configuration file using the “apachectl” command.

 apachectl configtest

Note and correct all/any errors.

When you are all set, perform a graceful apache restart.

 apachectl graceful

Make sure you spot check your rules in a browser to ensure they are working.