[pmwiki-users] Group and page name aren't recognized by pmwiki.php

[Joachim Durchholz]

Patrick R. Michaud wrote:
> [...] REQUEST_URI isn't even supplied by IIS.

Argh... I can't believe it. I have seen lots of misinterpreted or badly 
implemented standards, but this is worse than even the usual MS neglect.

>> Now let me propose another heuristics:
>> *if* PATH_INFO is set, let PmWiki take the group/page name from there.
>> This should be done between steps (2) and (3).
>> [...]
> 
> What about the cases where PATH_INFO is set wrongly?  This would
> throw things *way* off, because it would grab an incorrect
> PATH_INFO in preference to a correct SCRIPT_NAME/REQUEST_URI pair.

Agreed. Pity... (and not even Apache gets it right - I *really* wonder 
why people even bother doing CGI...)

We *could* try to parse PATH_INFO backwards, but that would generate all 
kinds of borderline cases, resulting in Microsoftish behavior (works 
most of the time but isn't reliable in the long term). Not a good 
alternative.

>> What do you think?
> 
> PmWiki's default is literally that -- a default that is designed
> to work on the widest variety of server/PHP configurations.  There's
> nothing to prevent a site from doing its own custom/exact
> processing of $pagename in local/config.php according to the
> server variables and other information available.

There's still a problem with that. config.php starts with the $pagename 
variable set, but it doesn't know where this information came from and 
how reliable it is.
For my configuration, this means that I don't know whether the 
information came from the query string (and hence is reliable) or came 
from PmWiki's attempt at parsing SCRIPT_NAME (which would be bogus). In 
other words, config.php wouldn't know whether it should do something or not.

I see several ways to solve this, in the order that they occurred to me 
(and some of them are so evil that I list them only for completeness):

1) Remove the SCRIPT_NAME heuristics from pmwiki.php. (The query string 
should be fine and can remain hardcoded.) Maybe make that heuristics 
available as a function that config.php can call after applying its own 
heuristics.
Pros: None.
Cons: Backwards-incompatible: $pagename may be unset when entering 
config.php.
2) Create a separate url-parse-config.php. First run the query string 
parse, if that fails, run url-parse-config.php if present, then (if 
$pagename is still unset) use the SCRIPT_NAME heuristics so that the 
rest of the PmWiki can assume that $pagename is always set.
Pros: Backwards-compatible.
Cons: Requires an additional configuration file, so installation becomes 
a little more complicated.
3) Use a status variable that tells config.php where the $pagename 
information came from.
Pros: None.
Cons: If the URL parse code ever changes, all installations that depend 
on the status variable will have to be reviewed.
4) Remove the path info parse from PmWiki. If there's no valid query 
string, simply default to Main.Home. People who want a PathInfo are 
encouraged to seek out mod_rewrite (and there's a Cookbook recipe for that).
Pros: PmWiki is decoupled from the idiosyncrasies of current web servers.
Cons: Breaks backwards compatibility. Requires rewriting all 
PathInfo-style URLs in pmwiki and in skins to query style. Would make 
PmWiki asymmetric, in that it would accept only query-style URLs but 
might emit PathInfo-style ones (an invitation to misconfigurations).

I don't like any of these alternatives, but I can't think of a better one.
Personally, I think that variant 2 is the least evil one.

Opinions?

Regards,
Jo