Upgrade of website followed by 403 errors on Apache RewriteRule

My Watkissonline.co.uk website is powered by WordPress on a Linux hosted server. It’s been on the server for some time and as a result was still running an old version of PHP and Mysql. WordPress has now increased it’s minimum requirement and therefore I needed an upgrade.

I asked my provider Compila.com for an upgraded version. They handled the move promptly and would have been minimal disruption, but for a couple of issues. This is in no way critical of Compila who handled this as well as I expected. I’m not sure the reason for the first problem, but the second was due to a feature of the new server that was enabled that I wasn’t aware of. Something that was a little tricky to pin-down, but which I solved eventually.

WordPress permissions problem

The first issue took the whole site down for a few minutes due to the permissions on my wordpress folder.

It was easy to fix once I spotted the problem. A quick look at the log showed the problem being related to permissions on the wordpress folder being too high – providing 777 access. I changed the permissions to 755 and that fixed it. This removed write access to the folder which can be a security risk.

Information on Linux file permissions – what 777 vs 755 actually means?

403 Errors

The second problem was harder to track down. I noticed that some of my main links on the page were giving 403 errors – which is an error that the directory listing was not permitted. Whilst these were all links that were similar to directory names they shouldn’t actually be returning directories at all. Here’s a little history behind the site which may help.

History of the website, manual html vs. WordPress CMS

The website was originally created by hand edited webpages using nothing more than a text editor. This had a number of directories which had default pages with links such as /info/ w hich would show /info/index.html (and later index.php). To make it easier to maintain I then moved my entire site into WordPress – using WordPress as a CMS as well as a blog. This made it much easier to keep the website up-to-date, but by default ended up with very cryptic urls. So instead of having /info/ I then had /wordpress/?page_id=2416 which doesn’t roll of the tongue quite so easily. I only wanted the user friendly names for the top few pages so mod_rewrite was a natural candidate: Guide to creating RewriteRules using Apache’s mod_rewrite module.

Because I wanted to keep the directories in place with some other files I created a RewriteRule for /info rather than /info/ which was the previous url.

An example RewriteRule entry is shown below. This would redirect /info to the WordPress page.
RewriteRule ^info$ /wordpress/?page_id=2416 [L]

Note that there is no / prefix on the filename which is because this is in .htaccess rather than in the vhosts configuration file (see: How to add mod_rewrite RewriteRules into .htaccess on a hosted website).

Temporary fix – using a redirect rule

I found that I could avoid the error by changing the RewriteRule to perform a redirect rather than just returning the alternate page seamlessly. Whilst this meant the site worked without any errors it didn’t hide the wordpress url from the user.

The updated rule was then:

RewriteRule ^info$ /wordpress/?page_id=2416 [R,L]

Help from the forum?

At this point I got stuck so turned to a forum for help. In this case WebmasterWorld.

The thread is available here: Thread on WebmasterWorld – 403 authoristion problem on RewriteRule which is being redirected

I didn’t get a direct answer for the problem, but I did get some pointers which helped me to figure out what the problem was and how to fix it.

Fixing the 403 authorisation errors (updated RewriteRule)

From the hints on the forum I realised that the url was being rewritten as a directory before the RewriteRule was being applied. The updated RewriteRule got rid of the 403 errors, by matching on the new directory name.

RewriteRule ^info/?$ /wordpress/?page_id=2416 [L]

It seams that the directory mapping happens before the RewriteRules, except where the RewriteRule was a redirect.

Using telnet to act as a web browser to see the http traffic

The browser hides some of the working behind the scenes so to investigate further I wanted to see what the browser was actually seeing. I therefore reached for the telnet client which with the right commands can reveal the real communication.

telnet www.watkissonline.co.uk 80
Trying 195.238.172.35...
Connected to watkissonline.co.uk.
Escape character is '^]'.
GET /info HTTP/1.1
Host: www.watkissonline.co.uk
Connection: Close

HTTP/1.1 301 Moved Permanently
Date: Thu, 07 Jul 2011 15:34:28 GMT
Server: Apache
Location: http://www.watkissonline.co.uk/info/?page_id=2416
Content-Length: 257
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.watkissonline.co.uk/info/?page_id=2416">here</a>.</p>
</body></html>
Connection closed by foreign host.


Lines in italic are the commands typed in.

From this I was able to identify that there was a redirect happening before the RewriteRule.

Disabling DirectorySlash directive in the mod_dir Apache module

After reading around the Apache documentation and searching the Internet for possible modules I found the DirectorySlash directive of the mod_dir module.

I added this to the .htaccess file after the Options and before the RewriteEngine on statement.

DirectorySlash Off

One of my options directives is -Indexes. If you do decide to turn DirectorySlash off on your own website then you should read the security warning at Apache mod_dir module.

Future

The end result is that my site is now on an upgraded version of PHP and MySQL and got my site working back how it was. I have not yet upgraded WordPress, which will be the next step.

I may look at moving the directories and/or links in future to make this a little easier to deal with in future.