Posts Tagged ‘htaccess files’

Howto check if mod_rewrite is installed and loaded in Apache 2.x and serving directories correctly

Wednesday, February 10th, 2010

During my professional experience as a system administrator, it was a common misfortune in newly
configured unix servers mod_rewrite not to be serving .htaccess files.
Everytime I had to fix issue in which mod_rewrite was not working I loosed a lot of my precious time
The same story happened once again I had to check why mod_rewrite is not configured correctly and I cannot
apply some redirection rules in WordPress necessery for me
to exercise some SEO on my wordpress blog .
Therefore this time I decided to blog a step by step check on in order to:

1. Determine if mod_rewrite is installed & loaded correctly in Apache
2. Find out if mod_rewrite is configured to serve .htaccess files correctly
Going through this two scenarios I would be able to determine why I cannot get wordpress SEO optimization
mod_rewrite redirection rules to work as they should.
Okay, so let’s go through the two scenarios:

1. Here is a tiny script in PHP to determine if mod_rewrite is installed and loaded in Apache correctly
To use the script save it somewhere in your Domain document root with a .php extension
Here is the code of the script as well:

< ?phpprint_r(apache_get_modules());?>

If your mod_rewrite module is configured correctly you’ll see it in the php array containing
all your apache loaded modules.

Without PHP from the shell in order to get installed Apache modules on Linux, the following command applies:

apache2ctl -t -D DUMP_MODULES

For apache 2.2.x
httpd (or apache.exe) -M will show static and shared modules loaded via LoadModule.
httpd -l will show only static (compiled in) modules

For apache 2.0.x
httpd (apache.exe) -l is available but -M is not.
You will need to manually check the LoadModule directives and the files.

2. Now we continue, further on with another script that has to be installed somewhere in Apache’s DocumentRoot
I decided to install it in a directory /test/ so in my case it’s installed in
Here is a link to the script you need to find out if mod_rewrite is configured to serve .htaccess files for your preferred domain name’s DocumentRoot.

Now save this file and again make sure it has a .php extension.

Now you need to create an .htaccess file in the directory where you have rewrite.php file stored.
The content of the .htaccess file should be the following:

RewriteEngine OnRewriteOptions InheritRewriteRule ^link([^/]*).html$ rewrite.php?link=$1 [L]

Make sure the permissions of the .htaccess are correct, for example the file should have at least read
permissions for your webserver.
So let’s execute:

chmod a+r .htaccess to ensure the newly created file has proper permissions
So let’s check if mod_rewrite is enabled for my domain DocumentRoot by visiting:
this link
Hopefully if all is okay you’ll see:
Congratulations!! You are using Apache mod_rewrite whenever you press the TEST2 link
on the upmentioned webpage.

In case if you get a 404 error message, then most probably you don’t have mod_rewrite configured
to serve .htaccess files for your domain.
This often happens because of missing:
AllowOverride All in your main Directory directives in your webserver configuration file.
In my case I had a problem where mod_rewrite rules were not red from the .htaccess file:
To solve my issue I had to change:

Directory /
AllowOverride None
Order Deny,Allow
Deny from all
in my httpd.conf to

Directory /
AllowOverride All
Order Deny,Allow
Deny from all

So well, That’s all Folks!

Speed up Apache webserver by including htaccess mod_rewrite rules in VirtualHosts / httpd.conf

Wednesday, November 12th, 2014

There are plenty of Apache Performance Optimization things to do on a new server. However many sysadmins miss  .htaccess mod_rewrite rules whole optimization often leads to a dramatic performance benefits and low webserver responce time, making website much more attractive for both Search Engine Crawlers and End User experience.

Normally most Apache + PHP CMS systems, websites, blogs etc. are configured to use various goodies of .htaccess files (mostly mod_rewrite rules, directory htpasswd authentication  and allow forbid directives). All most popular open-source Content management systems  like Drupal, Joomla, WordPress, TYPO3, Symphony CMS are configured to get use  .htaccess file usually living in the DocumentRoot of a virtualhost ( website/s )httpd.conf , apache2.conf /etc/apache2/sites-enabled/ or whichever config the Vhost resides…

It is also not uncommon practice to enable .htaccess files to make programmers life easier (allowing the coder to add and remove URL rewrite rules that makes URL pretty and SEO friendly, handle website redirection or gives live to the framework like it is the case with Zend PHP Framework).

However though having the possibility to get the advantages of dynamically using .htaccess inside site DocRoot or site's subdirectories is great for developers it is not a very good idea to have the .htaccess turned on Production server environment.


AllowOverride All

switched on for a directory in order to have .htaccess enabled, makes the webserver lookup for .htaccess file and re-read its content dynamically on each client request.
This has a negative influence on overall server performance and makes Apache preforked childs or workers (in case of mpm-worker engine used) to waste time parsing .htaccess file leading to slower request processing.

Normally a Virtualhost with enabled .htaccess looks like so:

ServerName …
DocumentRoot /var/www/website
<Directory /var/www/website>
AllowOverride All …
</Directory> …

And VirtualHost configured to keep permanently loaded mod_rewrite .htaccess rules in memory on Apache server start-up.

ServerName …
DocumentRoot /var/www/website
<Directory /var/www/website>
AllowOverride None
Include /var/www/website/.htaccess …
</Directory> …

Now CMS uses the previous .htaccess rules just as before, however to put more rewrite rules into the file you will need to restart webserver which is a downside of using rewrite rules through the Include directive. Using the Include directive instead of AllowOverride leads to 7 to 10% faster individual page loads.

I have to mention Include directive though faster has a security downside because .htaccess files loaded with Include option (uses mod_include) via httpd.conf doesn't recognize <Directory> … </Directory> set security rules. Also including .htaccess from configuration on Main Website directory, could make any other sub-directories .htaccess Deny / Allow access rules invalid and this could expose site to  security risk. Another security downside is because Include variable allows loading a full subset of Apache directives (including) loading other Apache configuration files (for example you can even override Virtualsthost pre-set directives such as ErrorLog, ScriptAlias etc.) and not only .htaccess standard directives allowed by AllowOverride All. This gives a potential website attacker who gains write permissions over the included /var/www/website/.htaccess access to this full set of VirtualHost directives and not only .htaccess standard allowed.

Because of the increased security risk most people recommend not to use Include .htaccess rules, however for those who want to get the few percentage page load acceleration of using static Include from Apache config, just set your Included .htaccess file to be owned by user/group root, e.g.:

chown root:root /var/www/website/.htaccess

Client Denied By Server Configuration Linux Apache error solution

Thursday, August 1st, 2013

Client denied by server configuration fix solution Apache feather logo

If you run Apache server on Debian Linux / Ubuntu / CentOS whatever Linux OS and you try to install a new PHP application under lets say /var/www/ getting an error in Apache error.log like:

[Wed Jul 31 03:36:21 2013] [error] [client] client denied by server configuration: /var/www/vea/index.php, referer:

This is due to misconfigured AllowOverrides in some of your main configuration files.

So what is causing the error?

Reason is by default in most current Linux distributions Apache is configured to have restrictive policy following the good security practice (Restrictive by default).
Apache is configured by default to not accept AllowOverrides – i.e. AllowOverride None for DocumentRoot /, because there are plenty of administrators who run Apache without having profound understanding leaving it to interpret by default mod_rewrite rules from .htaccess files etc.

To fix this issue, hence you have to add extra configuration for AllowOverride directive for directory giving the err. In this case /vea:

<Directory /var/www/vea/> 
Options -Indexes FollowSymLinks
AllowOverride AuthConfig
FileInfo Order allow,deny
Allow from all

Above rules are a bit restrictive and will allow only to have .htaccess with only for protecting directory with htaccess passsword for exmpl. – (AuthUserFile, AuthGroupFile, AuthName, AuthType) .htaccess.
-Indexes – instructs /var/www/vea directory listing to be disabled, below two lines:

Order allow, deny
Allow from all

Makes the directory Allowed to be visible by all, however note that it is possible in some of other Apache configuration files to have other rules configured for /vea documentroot /var/www/ which are preventive (Default Deny) – if this is the case just walk through all Apache configs and change where necessary to Allow from all.

In some cases it is possible Web application or Website placed requires AllowOverride All directive instead. If above <Directory>

does not help and you continue to get:

[Wed Jul 31 03:36:21 2013] [error] [client] client denied by server configuration: /var/www/php-application/index.php, referer:  

Try setting Directory rules with AllowOverride All ;

<Directory /var/www/php-application/> 
Options -Indexes FollowSymLinks
AllowOverride All
FileInfo Order allow,deny
Allow from all

Debian / Ubuntu server admins should check closely for AllowOverride rules in files /etc/apache2/conf.d/*

as well as in /etc/apache2/mods-available/*:

Usually there are AllowOverride rules set from files:


and also in


On Debian GNU / Linux, very common reason for getting client denied by server configuration is AllowOverride definitions in /etc/apache2/conf.d/security, default AllowOverride there are set to None, i.e.:

<Directory />
AllowOverride None
Order Deny,Allow
Deny from all

If that's the case with you make sure you config rules to become:

# <Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
# </Directory>

A very useful command to find where there is occurance of AllowOverride in Apache many configs is:

root@linux:~# cd /etc/apache2
root@linux:/etc/apache2# grep -rli AllowOverride *


Once you did all necessary config Restart Apache:

root@linux:~# /etc/init.d/apache2 restart