[pmwiki-users] pmwiki broken under Apache 2.2/PHP 5.1.2

Joachim Durchholz jo at durchholz.org
Sun Mar 26 11:23:56 CST 2006

Patrick R. Michaud schrieb:
> At least on your system, Apache 2.2 seems to have changed its value 
> for SCRIPT_NAME, which is what PmWiki has been using for deducing 
> the path info data.  (A lot of configurations have traditionally 
> provided incorrect PATH_INFO variables, which is why PmWiki went 
> to an alternate detection mechanism based on the SCRIPT_NAME
> and REQUEST_URI variables.)

It's probably not Apache but FastCgi. I had similar hiccups when 
transitioning from Cgi to FastCgi - PHP offers its own FastCgi daemon, 
initial versions were buggy and did the Wrong Thing with the environment 
variables. That bug seems to have persisted long enough that some PHP 
scripts relied on the buggy behavior; anyway, newer PHP releases don't 
fix the bug by default, but offer a cgi.fix_pathinfo directive for 
php.ini that activates the fix. (Well, I think the results are just 
slightly less buggy. PHP-under-FastCgi with cgi.fix_pathinfo switched on 
still doesn't give you the same environment as PHP-under-Cgi, or 

> I think the quick fix is to put 
>     $pagename = ResolvePageName($_SERVER['PATH_INFO']);
> at the top of your config.php.  
> Longer-term, I'll have to figure out how to get PmWiki to 
> properly detect the pagenames in yet-another-Apache-configuration
> possibility.  :-(  :-(

I'm not sure that the exact kind of CGI misinterpretation can be 
inferred from CGI data. Well, at least not easily; you'd need a 
regression test suite to make sure that adding support for some new kind 
of misconfiguration doesn't break support for an existing misconfiguration.


More information about the pmwiki-users mailing list