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

Patrick R. Michaud pmichaud at pobox.com
Wed Mar 23 15:22:48 CST 2005


On Wed, Mar 23, 2005 at 09:33:05PM +0100, Joachim Durchholz wrote:
> 
> I have a different idea: anything that starts with a lower-case 7-bit 
> ASCII character should be considered a URL that should be served from 
> the file system, everything else should be served via PmWiki, giving me 
> this rule:
> 
> RewriteCond %{REQUEST_URI} !^/*[a-z]
> RewriteRule ^(.*)$ pmwiki.php/$1 [L,NS]

Oooh, even nicer.  We can still rewrite this without the RewriteCond, however:

    RewriteRule ^([^a-z].*)$ pmwiki.php?n=$1 [L,qsappend]

> >Wrong--they absolutely *don't* break.  PmWiki internally converts 
> >PathInfo-style urls to query-syntax urls whenever $EnablePathInfo 
> >is not set.
> 
> This implies that PmWiki always recognizes PathInfo-style URLs even if 
> $EnablePathInfo is 0.
> 
> Is this correct?

Yes.  $EnablePathInfo is used to tell PmWiki what kind of urls to generate
on output.  PmWiki will always recognize a PathInfo-style URL if that's
what the webserver gives it.

> > --although the CGI spec clearly says that
> >this is what PATH_INFO is supposed to have, there are a *lot* of 
> >webservers, including Apache and PHP, that do not follow this 
> >part of the spec.  IIS is another one.
> 
> Hmm... I did a few experiments with Apache 1.3, and it worked perfectly. 
> In fact I have patched my site to use PATH_INFO, and it's been doing the 
> Right Thing all day.

All versions of Apache prior to 2.0.30 correctly handle PATH_INFO.
But, as I mentioned, some configurations of PHP do not -- they 
give you a PATH_INFO that consists of the entire url path, not 
just the part following the script name.

> However, I think the current solution can be improved.
> [...]
> If I'm interpreting the code correctly, PmWiki tries the following steps 
> in order until one succeeds:
> 1) Get _REQUEST ['n']. (Filled from ?n=... by PHP.)
> 2) Get _REQUEST ['pagename'].
> 3) Parse REQUEST_URI, under the assumption that it consists of
> _SERVER ['SCRIPT_NAME'], a slash, and the Group/Page name.
> 
> Step (3) actually is wrong: it shouldn't use SCRIPT_NAME, it should use 
> $ScriptUrl from config.php. 

It's worse than that, REQUEST_URI isn't even supplied by IIS.  But
so far this has worked on every Apache installation I've come across,
regardless of url rewriting.

> 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.

> 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.

Pm



More information about the pmwiki-users mailing list