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

[Joachim Durchholz]

Patrick R. Michaud schrieb:
 > [Things that I agree with snipped]
> 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?

I think the main problem with CleanUrls is that this configuration of 
PmWiki doesn't clearly distinguish file URLs from wikipage URLs. A wiki 
page looks like

   ...path/to/wiki/Group/Name

while a file URL looks like

   ...path/to/wiki/pub/skins/pmwiki

What makes matters worse is that anybody could create a "Pub" group, and 
on a case-insensitive file systems, the administrator will be utterly 
confused why

   ...path/to/wiki/Pub/MyPub

is served in an entirely different way than

   ...path/to/wiki/pub/mypub/pmwiki.css

(until he's reminded that URL space is always case-sensitive... but even 
if you know that, it's easy to confuse that if you're in a hurry).

Personally, if I see somebody designing file URLs into a wiki, my 
knee-jerk reaction is "separate the URL spaces!"

E.g. I'd tell them to do

   ...path/to/wiki/pages/Pub/MyPub
vs.
   ...path/to/wiki/pub/skins/pmwiki/pmwiki.css

After that, people can serve static pages (or even scripts) from outside 
the wikipage namespace to their heart's contents, without requiring 
mod_rewrite magic to properly guess whether it's a file or a wikipage 
that should be served.

The "simply serve it as a file if it exists" approach has too much 
overlap with other policies; it creates a tangle of responsibilities, in 
a server where getting the security right is too difficult already.

It would be better if everything inside PmWiki's URL space were handled 
by PmWiki.
Yes, this means that PmWiki should serve everything through pmwiki.php, 
even if it is "just" serving a file unchanged. But then PmWiki can place 
a single, sane permission scheme; right now, you have to know *three* 
things to correctly determine whether something will be served:
* Whether it's a file or a wiki page
* PmWiki's security policy
* Apache's security policy
That's two things too many IMNSHO.

Oh, and then there are the other problems that I mentioned in my replies 
to Hagan. I think it's a great idea, and probably one that works best 
for his specific situation, but I don't think it should be generally 
applied - at least not unless the administrator has a clear idea of what 
he's doing (i.e. the kind of guy who writes Cookbook pages, not the kind 
of guy who reads them).

Just my 2c.

Oh, and my recommendation: Leave that policy in the CleanUrls page, but 
mention the alternatives.
I agree the page is confusing. However, I don't think that's because 
it's listing too many alternatives; the confusion comes from having too 
many alternatives and no proposals for choosing the right one.
In other words, the page should be structured like this:
* If you have situation (a) and (b), do alternative (1).
* If you have situation (c), do alternative (2).
With clear instructions how to find out what situation you have. (The 
"situation" involves things like: Apache setup, URL space policy, 
whether public uploads are enabled, etc.)
Writing that would be a major endeavour; i.e. it would move the burden 
of finding out from the shoulders of the recipe readers to the shoulders 
of the recipe writer. But it *should* be done. (By somebody. I don't 
have the breadth of experience to do it with any confidence, and have 
too many other things in the pipeline already.)

Regards,
Jo