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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] Then again same happens with Apache too.. ------------------------------------------------------------------------ [2007-08-07 11:41:19] [EMAIL PROTECTED] 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
