[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