ID: 42198
User updated by: hans at parse dot nl
Reported By: hans at parse dot nl
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
Ah, i didn't know about the Apache ticket but it looks like exactly the
same issue. Nice work on that, hope it makes it into php-5.2.4 :)
I applied your patch to php-5.2.4RC1 and adapted Lighttpd mod_fastcgi.c
so it exactly matches your Apache results.
My patch for lighttpd-1.4.16 can be found here:
http://home.parse.nl/~hans/temp/mod_fastcgi.diff
Can you please check if you get proper results with it aswell? Would be
great if we can tackle this :)
Previous Comments:
------------------------------------------------------------------------
[2007-08-07 13:10:10] jani@php.net
And FYI, about PHP_SELF:
http://www.php.net/reserved.variables
(yes, it's supposed to contain PATH_INFO..)
------------------------------------------------------------------------
[2007-08-07 13:08:05] jani@php.net
See bug #31892 (It's about Apache)
I fixed the issues there with this patch (against latest CVS checkout
of PHP_5_2):
http://pecl.php.net/~jani/patches/bug_31892.patch
I then tried the same on lighttpd but no luck: Lighttpd sets
PATH_TRANSLATED incorrectly, debugged it and saw it was set to this:
PATH_TRANSLATED: /opt/www//foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php
PHP_SELF: /r/t.php
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
Obviously when there's this alias/userdir lighttpd still uses document
root to set the PATH_TRANSLATED with (I checked the actual value
lighttpd sets it to, it's not the one PHP modifies..).
Lighttpd seems to ignore the script name totally too. Under apache it
now works (when my patch is applied) as expected:
PATH_TRANSLATED: /home/jani/t.php/foo/bar/
PATH_INFO: /foo/bar/
SCRIPT_FILENAME: /home/jani/t.php
SCRIPT_NAME: /r/t.php/foo/bar/
PHP_SELF: /r/t.php/foo/bar/
REQUEST_URI: /r/t.php/foo/bar/?bar=foo
------------------------------------------------------------------------
[2007-08-07 12:35:44] hans at parse dot nl
Heh i was pondering and typing a apache2handler example and then i saw
your Apache comment. Here it is anyway:
--
Yes i agree, my patch is kinda hacky but solved my personal userdir
problem ;) The alias problem was someone else's which i overlooked.
Your alias example suffers from the same problem as userdirs, being
that the DOCUMENT_ROOT always points to the docroot of the host, but as
i already pointed out, this is also the case in apache/mod_php5 or
apache2handler, not just cgi-fcgi.
apache2handler actually is an even bigger mess :) for example:
request: http://www.site.com/~hans/info.php/foo/bar
result:
_SERVER["DOCUMENT_ROOT"] /var/www/site.com/www/htdocs
_SERVER["REQUEST_URI"] /~hans/info.php/foo/bar
_SERVER["SCRIPT_NAME"] /~hans/info.php
_SERVER["PATH_INFO"] /foo/bar
_SERVER["PATH_TRANSLATED"] /var/www/site.com/www/htdocs/foo/bar
_SERVER["PHP_SELF"] /~hans/info.php/foo/bar
Not really consistent, and also an invalid PATH_TRANSLATED, and
PATH_INFO added to PHP_SELF ?!
Anyway, back to Lighttpd. I'll try to whip up a less hacky fix that
also handles the aliases.
------------------------------------------------------------------------
[2007-08-07 11:51:55] jani@php.net
Then again same happens with Apache too..
------------------------------------------------------------------------
[2007-08-07 11:41:19] jani@php.net
You patch does not fix the issue for anything but the userdir module
and in a very hackish way. For the aliasing part of your (saw your
example on the lighttpd bug report) it does not fix it at all.
When I debugged this I noticed this:
["PATH_TRANSLATED"]=>
string(17) "/opt/www/foo/bar/"
["SCRIPT_FILENAME"]=>
string(16) "/home/jani/t.php"
["DOCUMENT_ROOT"]=>
string(9) "/opt/www/"
["REQUEST_URI"]=>
string(17) "/r/t.php/foo/bar/"
Shouldn't DOCUMENT_ROOT be /home/jani/ in this case when it's the
alias? And PATH_TRANSLATED is also wrong..
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42198--
Edit this bug report at http://bugs.php.net/?id=42198&edit=1