[pmwiki-users] case-insensitive Rewrite Rules [was: How use lowercase in Group Names]

Waylan Limberg waylan at gmail.com
Thu Sep 29 10:57:31 CDT 2005

The original discussion has taken a few different directions, so I'm
breaking this part off to make it easier to follow and find later. For
those who missed it, we are looking for rewrite rules that allow
case-insensitive or lowercase URLs that point to page names (how
PmWiki handles those lowercase requests is another matter dicussed
elsewhere), but also allow through requests to other files on the
server. Currently, all URLs with uppercase letters are passed to
PmWiki and all lowercase requests are not.

On 9/28/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Wed, Sep 28, 2005 at 01:47:05PM -0400, Waylan Limberg wrote:
> > Anyway, later I came across another project
> > that used an interesting approach to the rewrite rules. They were in
> > part as follows (modified for PmWiki):
> >
> > RewriteCond %{REQUEST_FILENAME} !-f
> > RewriteRule ^(.*)$ phwiki.php?n=$1 [QSA,L]
> Very interesting -- I'll need to look at that a bit further!  Excellent
> find, and thanks!

Your welcome. I just ran a test on that exactly as it appears above
and got some interesting results (it was passing things through to
PmWiki fine, but not properly returning existing files).  After
playing with it I found that this seems to work fine:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^.]+)$ phwiki.php?n=$1 [QSA,L]

* Requests to existing wiki pages returns those pages
* Requests for non-existent wiki pages returns an offer to create that page
* Requests to existing files on the server (images, stylesheets,
attachments, etc.) returns said file
* And requests to restricted files (such as those in local dir)
returns "500 Internal Server Error" - the same at before.

I should note that I also have "DirectoryIndex pmwiki.php" in my
.htaccess file as well. When I commented it out and requested the
server root (.../) I also got the '500' response. Of course, there are
other ways around that that I'm not using. Adding the following before
the RewriteCond seems to do the trick:

RewriteRule ^/?$ pmwiki.php [QSA]

I suppose that could always be adjusted or removed if someone wants
something different at the default index page. Personally, I'll
continue to use DirectoryIndex as long as my host allows it. As I
understand it, that should be just a little easier on the server than
another rewrite rule.

And of course, if PmWiki is not at the server root add this before any
rewrite rules:

RewriteBase /path/to/wiki/

So in the end, the .htaccess file would look like this:

## Uncomment to define directory index if allowed by your servers config
## You may want to comment out the first rewrite rule below if you use this.
# DirectoryIndex pmwiki.php

## Uncomment and edit path if PmWiki is not in the server root
## (ie. for "example.com/wiki/pmwiki.php" use "RewriteBase /wiki/")
# RewriteBase /path/to/wiki/

## Point empty URL to PmWiki, allowing PmWiki to determine default page
## If your server config allows defining DirectoryIndex,
## you may comment this out and use that instead.
RewriteRule ^/?$ pmwiki.php [QSA]

## It file does not exist, send request to PmWiki
## Otherwise allow Apache to serve requested file as normal
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^.]+)$ phwiki.php?n=$1 [QSA,L]

If some others could use this and see if they can break it, that would
be much appreciated. Once we determine that this (or some better
variant) will work, I'll add it to a cookbook (or perhaps create a new

Oh yeah, so that credit goes where credit is due, I came across the
consept for the RewriteCond looking at the Ruby on Rails project Typo.
I don't know, maybe all RoR projects use this technic
Waylan Limberg
waylan at gmail.com

More information about the pmwiki-users mailing list