mod_rewrite issues on Leopard

[splashtech]

I am having a very strange issue using mod_rewrite under Leopard. Take the following example:

- In my ~/Sites folder, I have a folder called mysite_v1, which contains several PHP files and a .htaccess file with the following contents:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=40]

RewriteRule ^portfolio$ portfolio.php [QSA,L]
RewriteRule ^portfolio/$ portfolio.php [QSA,L]

RewriteRule ^portfolio/(.*$) portfolioview.php?proj=$1 [QSA,L]

RewriteRule ^about$ about.php [QSA,L]
RewriteRule ^contact$ contact.php [QSA,L]

- All the files required by the rewrites exist in the same folder.

- When I visit http://localhost/~my-username/mysite_v1/about.php, it works fine. This proves the file does in fact exist and is available correctly to apache.

However - when I visit http://localhost/~my-username/mysite_v1/about, which should be remapped to the above URL, it fails with a 404 and the following message:

Not Found

The requested URL /Users/my-username/Sites/mysite_v1/about.php was not found on this server.

This proves the mod_rewrite rules are working fine, since its looking for about.php, not simply about. But for some reason, it seems convinced it does not exist when it definitely does.

Here is the configuration file apache uses for my user-specific sites:

<Directory "/Users/my-username/Sites/">
    Options Indexes FollowSymlinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

AccessFileName .htaccess

The Options FollowSymlinks option is present, which is (apparently) required for mod_rewrite to work. But for some reason, it isnt. The same .htaccess file (all the same rewrites) work perfectly on my old windows machine.

I'm totally baffled as to what's going on here. This simply should be working. Does anyone have any ideas what is going on or what I may have overlooked, and is this a Leopard-specific issue maybe?

Additional details: I am using the version of Apache and PHP provided with Leo, not a 3rd party package or self-compiled version.

Edit: I should probably also mention that I have removed all occurances of Options MultiViews because I didnt want that behaviour as I do not use it on my production servers - and it was taking precedence over the rewrites.

 

[angelwatt]

Well the easiest possible solution is to make sure you restarted the Apache web server after making the change. I'm no .htaccess file expert so I'm not sure if your code there is completely write, but does seem to match some of what I have in my own. The only difference is that I don't use the QSA option, just the L at the end of the RewriteRule. I'm running it on a Windows machine though as well, though shouldn't really make a difference. I also have this set on my httpd.conf rather than a .htaccess.

 

[splashtech]

I did restart the apache server after making each change to the .conf files.

Your comment about the flags made me wonder if perhaps it was those which were somehow affecting it - although as I mentioned Windows with Apache 2.0 and 2.2 were fine. I tried it just with the L option and it made no difference. I decided to google for further information and I have still yet to get to the bottom of it, using any of the following:
[QSA,L]
[L]
<none at all>
[PT]
[NC]
and several combinations of the above.

My conclusion is that the flags are not the issue - it still seems to be going to the correct place but convinced the file does not exist when it does.

This is very strange.

 

[splashtech]

Found the answer

This may be of use in case anybody else encounters the same problem.

I needed to specify a RewriteBase value as well, set to /~my-username/mysite_v1. Once this was added, it all started working.

The documentation for mod_rewrite explains it:

The RewriteBase directive explicitly sets the base URL for per-directory rewrites. As you will see below, RewriteRule can be used in per-directory config files (.htaccess). In such a case, it will act locally, stripping the local directory prefix before processing, and applying rewrite rules only to the remainder. When processing is complete, the prefix is automatically added back to the path. The default setting is; RewriteBase physical-directory-path

When a substitution occurs for a new URL, this module has to re-inject the URL into the server processing. To be able to do this it needs to know what the corresponding URL-prefix or URL-base is. By default this prefix is the corresponding filepath itself. However, for most websites, URLs are NOT directly related to physical filename paths, so this assumption will often be wrong! Therefore, you can use the RewriteBase directive to specify the correct URL-prefix.

If your webserver's URLs are not directly related to physical file paths, you will need to use RewriteBase in every .htaccess file where you want to use RewriteRule directives.

-- mod_rewrite documentation

My previous system was in effect trying to access http://localhost/Users/my-username/Sites/mysite_v1 which is why it was failing with a 404. I hadn't encountered such a problem before since on windows I worked straight out of the main apache htdocs root (with subfolders), rather than the per-user folder as I am on Leopard. And due to the differing way Windows treats the "server root", it was pretty much a non issue anyway. All production servers have been configured in such a way that this was a non-issue too.

I won't be able to use the same .htaccess files on both development and production anymore, but that is a minor complaint and can be handled as part of the deployment for each site.

Hope this helps someone else as well as me