[pmwiki-users] CleanUrls, again (was: Putting ".html" extensions...)

[Patrick R. Michaud]

Here's my brief thoughts on the "lowercase" versus "file exists"
discussion surrounding CleanUrls.  

Just to restate things:  the "lowercase" version says that Apache
directly serves any url path beginning with a lowercase letter, and
passes all others to PmWiki.  The "file exists" version says that
Apache directly serves any url path that corresponds to an existing 
file, and passes all others to PmWiki.

My comments:

 -  I agree with Hagan that the topic is so complex (and there
    are so many options) that the CleanUrls page should focus on a
    single consistent approach, and not try to describe all of the
    ways to do it.

For the "file exists" approach:
   
 -  For case-sensitive filesystems, the issue of accidental file and 
    page collisions -- e.g., a file called "LICENSE" suddenly appears
    in the installation directory -- matters *only* if one is doing
    clean urls from within the pmwiki/ directory (this is "Example One"
    in the current CleanUrls page).  At the moment there aren't any
    files in a PmWiki distribution that can conflict, nor are there
    likely to be in the future (and we can easily work around it then
    if it needs to be done).

 -  For case-insensitive filesystems, there are a lot more
    opportunities for conflict -- many group urls will not work with
    the "file exists" approach:

        .../pmwiki/Docs
        .../pmwiki/Cookbook
        .../pmwiki/Scripts
        .../pmwiki/Local

    Again, this only occurs in the case where clean urls are being
    done from within the pmwiki/ directory.  If one is doing clean urls
    from the directory above ("Example Two"), then it primarily
    affects the PmWiki group and pages in the PmWiki group, but it
    can also produce collisions if there are any other subdirectories
    or files at the level where the clean urls is being performed.

 -  One caveat to this approach is that all incoming requests 
    that don't correspond to files get passed to PmWiki, including
    those that would've resulted in a 404 Page Not Found from the
    web server.  This could be seen as either a benefit or a drawback,
    depending on the application.  Its impact can also be limited
    somewhat by restricting the rewrite pattern to those urls that
    can actually match a valid pagename.

Given the limitations of the "file exists" approach above, I
should note that my experience has been that admins are equally
confused by the "lowercase" approach as well, especially when
clean urls is being used to enable pages from the root.

I don't have a strong hard-and-fast answer for which approach
the clean urls page should use.  Because there's potential for
difficulty with the "file exists" approach on case-insensitive
filesystems, I think I'd tend towards using lowercase letters
as the primary distinguishing method.

But I also think it doesn't have to be an "either-or" situation --
we can always do both.  Suppose we take the basic clean urls
.htaccess structure as sending non-lowercase urls to PmWiki:

    # Use mod_rewrite to enable "Clean URLs" for a PmWiki installation.
    RewriteEngine On
    # The rewrite base will be the document root.
    RewriteBase /
    # Send requests without parameters to pmwiki.php.
    RewriteRule ^$           ~someuser/pmwiki/pmwiki.php  [L]
    # Send requests for index.php to pmwiki.php.
    RewriteRule ^index.php$  ~someuser/pmwiki/pmwiki.php  [L]
    # Send requests to pmwiki.php, appending the query string part.
    RewriteRule ([^a-z].*)   ~someuser/pmwiki/pmwiki.php?n=$1  [QSA,L]

Then for those sites and admins that want to also directly serve 
files that begin with other characters, we add a subsection 
after example three that looks something like:

    !!! Serving files and directories with uppercase letters

    To allow url requests for files or directories that begin
    with uppercase letters to continue to work, add the following
    lines immediately before the last RewriteRule above:

        RewriteCond %{REQUEST_FILENAME}  !-f
        RewriteCond %{REQUEST_FILENAME}  !-d

Is that workable?

Pm