#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682 Comment by: hans at parse dot nl Reported By: Slig at free dot fr Status: Open Bug Type: Streams related Operating System: linux-64 PHP Version: 5CVS-2007-10-11 (snap) New Comment: php-5.2.6RC5 seems to solve this issue. Just tested with -O2 optimizations and the testcase returns the expected result. Previous Comments: [2008-04-16 07:59:38] hans at parse dot nl More info: Upgraded to gcc-4.2.3 to check for possible gcc-related issue. Recompiled entire system overnight. Problem persists. Since the last response from a php devver is almost 6 months back, it would be very welcome to see some response on these latest additions. [2008-04-15 11:28:27] hans at parse dot nl Just did a final test and recompiled php with gcc optimization set to -O1 instead of -O2 used in previous tests, and i can confirm that compiling with -O1 eliminates the problem aswell. So to summarize: -changing this_fd from int to long eliminates the problem -compiling without openssl eliminates the problem, though this is obviously not an option in most cases -compiling without gcc optimizations eliminates the problem So now the question is, is this a gcc, a php or a openssl problem? I'm willing to test and provide you with all necessary information. [2008-04-15 10:52:40] hans at parse dot nl Problem persists in 5.2.6RC4. Tested using the testcase above, on a freshly installed Athlon64 Gentoo system. Tested against the following openssl versions: openssl-0.9.8g openssl-0.9.8e openssl-0.9.7i Recompiled php-5.2.6RC4 ebuild after each openssl version change. All versions exhibit same erroneous behavior, as described in the initial bugreport. Compiling php without openssl support eliminates the problem, as reported earlier. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 php-5.2.6RC4 (using dev-lang/php-5.2.6_rc4 gentoo ebuild) [2008-02-22 10:50:32] hans at parse dot nl This is stil a pretty serious issue on x86_64. Just ran into this one while swapping out a bunch of x86 webservers for new x86_64 boxes. Both the new and the old boxes run Gentoo, with the same gcc version, same php version. The 32 bit boxes were fine, the new 64 bit boxes fail on all stream fread's due to this issue. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 openssl-0.9.8g php-5.2.5 (using php-5.2.5-r1 gentoo ebuild) [2007-10-22 11:00:26] [EMAIL PROTECTED] Is there difference between openssl versions on those Suse/Centos machines? 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/42682 -- Edit this bug report at http://bugs.php.net/?id=42682&edit=1
#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682 Comment by: hans at parse dot nl Reported By: Slig at free dot fr Status: Open Bug Type: Streams related Operating System: linux-64 PHP Version: 5CVS-2007-10-11 (snap) New Comment: More info: Upgraded to gcc-4.2.3 to check for possible gcc-related issue. Recompiled entire system overnight. Problem persists. Since the last response from a php devver is almost 6 months back, it would be very welcome to see some response on these latest additions. Previous Comments: [2008-04-15 11:28:27] hans at parse dot nl Just did a final test and recompiled php with gcc optimization set to -O1 instead of -O2 used in previous tests, and i can confirm that compiling with -O1 eliminates the problem aswell. So to summarize: -changing this_fd from int to long eliminates the problem -compiling without openssl eliminates the problem, though this is obviously not an option in most cases -compiling without gcc optimizations eliminates the problem So now the question is, is this a gcc, a php or a openssl problem? I'm willing to test and provide you with all necessary information. [2008-04-15 10:52:40] hans at parse dot nl Problem persists in 5.2.6RC4. Tested using the testcase above, on a freshly installed Athlon64 Gentoo system. Tested against the following openssl versions: openssl-0.9.8g openssl-0.9.8e openssl-0.9.7i Recompiled php-5.2.6RC4 ebuild after each openssl version change. All versions exhibit same erroneous behavior, as described in the initial bugreport. Compiling php without openssl support eliminates the problem, as reported earlier. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 php-5.2.6RC4 (using dev-lang/php-5.2.6_rc4 gentoo ebuild) [2008-02-22 10:50:32] hans at parse dot nl This is stil a pretty serious issue on x86_64. Just ran into this one while swapping out a bunch of x86 webservers for new x86_64 boxes. Both the new and the old boxes run Gentoo, with the same gcc version, same php version. The 32 bit boxes were fine, the new 64 bit boxes fail on all stream fread's due to this issue. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 openssl-0.9.8g php-5.2.5 (using php-5.2.5-r1 gentoo ebuild) [2007-10-22 11:00:26] [EMAIL PROTECTED] Is there difference between openssl versions on those Suse/Centos machines? [2007-10-12 18:25:57] margus at zone dot ee Perhaps it helps if I give test results on different machines and where and how it manifests: stream_select() works flawlessly without patching on: - my multiple 32bit machines. Those have SuSE90 or SuSE93 installed. - my multiple 64bit SuSE10 machines stream_select() works only when patched 'long this_fd;' or 'long this_fd=0;' on: - my multiple 64bit CentOS 4.5 systems (Xeon Quadcore) stream_select() works only when patched 'long this_fd=0;' (stream_select segfaults without variable initializing) on: - my one 64bit CentOS 4.5 machine (Opteron Dualcore). Origin of this bug must be somewhere in php_stream_cast() or even lower. I tried also compiling without OpenSSL support and yes, the bug along with SSL socket support can be "eliminated" this way too :) 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/42682 -- Edit this bug report at http://bugs.php.net/?id=42682&edit=1
#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682 Comment by: hans at parse dot nl Reported By: Slig at free dot fr Status: Open Bug Type: Streams related Operating System: linux-64 PHP Version: 5CVS-2007-10-11 (snap) New Comment: Just did a final test and recompiled php with gcc optimization set to -O1 instead of -O2 used in previous tests, and i can confirm that compiling with -O1 eliminates the problem aswell. So to summarize: -changing this_fd from int to long eliminates the problem -compiling without openssl eliminates the problem, though this is obviously not an option in most cases -compiling without gcc optimizations eliminates the problem So now the question is, is this a gcc, a php or a openssl problem? I'm willing to test and provide you with all necessary information. Previous Comments: [2008-04-15 10:52:40] hans at parse dot nl Problem persists in 5.2.6RC4. Tested using the testcase above, on a freshly installed Athlon64 Gentoo system. Tested against the following openssl versions: openssl-0.9.8g openssl-0.9.8e openssl-0.9.7i Recompiled php-5.2.6RC4 ebuild after each openssl version change. All versions exhibit same erroneous behavior, as described in the initial bugreport. Compiling php without openssl support eliminates the problem, as reported earlier. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 php-5.2.6RC4 (using dev-lang/php-5.2.6_rc4 gentoo ebuild) [2008-02-22 10:50:32] hans at parse dot nl This is stil a pretty serious issue on x86_64. Just ran into this one while swapping out a bunch of x86 webservers for new x86_64 boxes. Both the new and the old boxes run Gentoo, with the same gcc version, same php version. The 32 bit boxes were fine, the new 64 bit boxes fail on all stream fread's due to this issue. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 openssl-0.9.8g php-5.2.5 (using php-5.2.5-r1 gentoo ebuild) [2007-10-22 11:00:26] [EMAIL PROTECTED] Is there difference between openssl versions on those Suse/Centos machines? [2007-10-12 18:25:57] margus at zone dot ee Perhaps it helps if I give test results on different machines and where and how it manifests: stream_select() works flawlessly without patching on: - my multiple 32bit machines. Those have SuSE90 or SuSE93 installed. - my multiple 64bit SuSE10 machines stream_select() works only when patched 'long this_fd;' or 'long this_fd=0;' on: - my multiple 64bit CentOS 4.5 systems (Xeon Quadcore) stream_select() works only when patched 'long this_fd=0;' (stream_select segfaults without variable initializing) on: - my one 64bit CentOS 4.5 machine (Opteron Dualcore). Origin of this bug must be somewhere in php_stream_cast() or even lower. I tried also compiling without OpenSSL support and yes, the bug along with SSL socket support can be "eliminated" this way too :) [2007-10-12 17:17:10] Slig at free dot fr No, just setting it to 0 doesn't work. And margus is true, using 'long this_fd;' it works (with or without setting it to 0). I don't say it's the right solution, perhaps it's more something to change in php_stream_cast(), i don't know. 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/42682 -- Edit this bug report at http://bugs.php.net/?id=42682&edit=1
#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682 Comment by: hans at parse dot nl Reported By: Slig at free dot fr Status: Open Bug Type: Streams related Operating System: linux-64 PHP Version: 5CVS-2007-10-11 (snap) New Comment: Problem persists in 5.2.6RC4. Tested using the testcase above, on a freshly installed Athlon64 Gentoo system. Tested against the following openssl versions: openssl-0.9.8g openssl-0.9.8e openssl-0.9.7i Recompiled php-5.2.6RC4 ebuild after each openssl version change. All versions exhibit same erroneous behavior, as described in the initial bugreport. Compiling php without openssl support eliminates the problem, as reported earlier. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 php-5.2.6RC4 (using dev-lang/php-5.2.6_rc4 gentoo ebuild) Previous Comments: [2008-02-22 10:50:32] hans at parse dot nl This is stil a pretty serious issue on x86_64. Just ran into this one while swapping out a bunch of x86 webservers for new x86_64 boxes. Both the new and the old boxes run Gentoo, with the same gcc version, same php version. The 32 bit boxes were fine, the new 64 bit boxes fail on all stream fread's due to this issue. Target: x86_64-pc-linux-gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) glibc-2.6.1 openssl-0.9.8g php-5.2.5 (using php-5.2.5-r1 gentoo ebuild) [2007-10-22 11:00:26] [EMAIL PROTECTED] Is there difference between openssl versions on those Suse/Centos machines? [2007-10-12 18:25:57] margus at zone dot ee Perhaps it helps if I give test results on different machines and where and how it manifests: stream_select() works flawlessly without patching on: - my multiple 32bit machines. Those have SuSE90 or SuSE93 installed. - my multiple 64bit SuSE10 machines stream_select() works only when patched 'long this_fd;' or 'long this_fd=0;' on: - my multiple 64bit CentOS 4.5 systems (Xeon Quadcore) stream_select() works only when patched 'long this_fd=0;' (stream_select segfaults without variable initializing) on: - my one 64bit CentOS 4.5 machine (Opteron Dualcore). Origin of this bug must be somewhere in php_stream_cast() or even lower. I tried also compiling without OpenSSL support and yes, the bug along with SSL socket support can be "eliminated" this way too :) [2007-10-12 17:17:10] Slig at free dot fr No, just setting it to 0 doesn't work. And margus is true, using 'long this_fd;' it works (with or without setting it to 0). I don't say it's the right solution, perhaps it's more something to change in php_stream_cast(), i don't know. [2007-10-12 10:10:34] [EMAIL PROTECTED] But it won't work in future. I tried to figure out why changing that int to long would help but AFAICT it's really supposed to be int since everything else using this_fd is expecting it to be int.. 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/42682 -- Edit this bug report at http://bugs.php.net/?id=42682&edit=1
#42682 [Com]: stream_select() indicates bad number of readable descriptors
ID: 42682
Comment by: hans at parse dot nl
Reported By: Slig at free dot fr
Status: Open
Bug Type: Streams related
Operating System: linux-64
PHP Version: 5CVS-2007-10-11 (snap)
New Comment:
This is stil a pretty serious issue on x86_64. Just ran into this one
while swapping out a bunch of x86 webservers for new x86_64 boxes.
Both the new and the old boxes run Gentoo, with the same gcc version,
same php version. The 32 bit boxes were fine, the new 64 bit boxes fail
on all stream fread's due to this issue.
Target: x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)
glibc-2.6.1
openssl-0.9.8g
php-5.2.5 (using php-5.2.5-r1 gentoo ebuild)
Previous Comments:
[2007-10-22 11:00:26] [EMAIL PROTECTED]
Is there difference between openssl versions on those Suse/Centos
machines?
[2007-10-12 18:25:57] margus at zone dot ee
Perhaps it helps if I give test results on different machines and where
and how it manifests:
stream_select() works flawlessly without patching on:
- my multiple 32bit machines. Those have SuSE90 or SuSE93 installed.
- my multiple 64bit SuSE10 machines
stream_select() works only when patched 'long this_fd;' or 'long
this_fd=0;' on:
- my multiple 64bit CentOS 4.5 systems (Xeon Quadcore)
stream_select() works only when patched 'long this_fd=0;'
(stream_select segfaults without variable initializing) on:
- my one 64bit CentOS 4.5 machine (Opteron Dualcore).
Origin of this bug must be somewhere in php_stream_cast() or even
lower. I tried also compiling without OpenSSL support and yes, the bug
along with SSL socket support can be "eliminated" this way too :)
[2007-10-12 17:17:10] Slig at free dot fr
No, just setting it to 0 doesn't work.
And margus is true, using 'long this_fd;' it works (with or without
setting it to 0). I don't say it's the right solution, perhaps it's more
something to change in php_stream_cast(), i don't know.
[2007-10-12 10:10:34] [EMAIL PROTECTED]
But it won't work in future. I tried to figure out why changing that
int to long would help but AFAICT it's really supposed to be int since
everything else using this_fd is expecting it to be int..
[2007-10-11 18:50:17] margus at zone dot ee
I was hit by the same annoying bug (CentOS 4.5/x64/PHP5.1.6 & 5.2.3)
After debugging PHP stream_select() I found out that system's select()
returns correct number but this value get's mysteriously set to zero
(memory is overwritten?) a few steps before returning it to PHP script.
Anyway, the cure for me was to change an variable type from int to long
and explicitly reset it to 0. This patch works for both PHP 5.1 and
5.2:
--- ext/standard/streamsfuncs.c.orig2007-10-09 16:21:30.0
+0300
+++ ext/standard/streamsfuncs.c 2007-10-09 16:21:41.0 +0300
@@ -608,7 +608,7 @@
zval **elem, **dest_elem;
php_stream *stream;
HashTable *new_hash;
- int this_fd, ret = 0;
+ long this_fd = 0, ret = 0;
if (Z_TYPE_P(stream_array) != IS_ARRAY) {
return 0;
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/42682
--
Edit this bug report at http://bugs.php.net/?id=42682&edit=1
#42453 [NEW]: CGI SAPI does not shut down cleanly with -i/-m/-v cmdline options
From: hans at parse dot nl Operating system: Linux PHP version: 5.2.4RC3 PHP Bug Type: CGI related Bug description: CGI SAPI does not shut down cleanly with -i/-m/-v cmdline options Description: The CGI SAPI initializes extensions through the regular MINIT/RINIT functions, but lacks a call to php_request_shutdown() for proper extension shutdown on some command line options. This is the case for command line options -v, -i and -m, which call exit(0) without requesting module/extension shutdown first. The CLI SAPI *does* clean up nicely after -v/-i/-m and does not exhibit this behavior. Reproduce code: --- With CGI SAPI: # php-cgi -v PHP 5.2.4RC3 (cgi-fcgi) (built: Aug 27 2007 16:51:33) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator [23661] EACCELERATOR: PHP unclean shutdown With CLI SAPI: # php -v PHP 5.2.4RC3 (cli) (built: Aug 27 2007 16:51:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator Expected result: nice clean shutdown through RSHUTDOWN/MSHUTDOWN. Actual result: -- exit(0) without shutting down modules/extensions -- Edit bug report at http://bugs.php.net/?id=42453&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42453&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42453&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42453&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42453&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42453&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42453&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42453&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42453&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42453&r=support Expected behavior:http://bugs.php.net/fix.php?id=42453&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42453&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42453&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42453&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42453&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42453&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42453&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42453&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42453&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42453&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42453&r=mysqlcfg
#42198 [Fbk->Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
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
#42198 [Fbk->Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
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:
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.
Previous Comments:
[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..
[2007-08-07 09:23:00] hans at parse dot nl
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l && env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
"trailing slash check if loop" is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
--
#42198 [Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
ID: 42198
User updated by: hans at parse dot nl
Reported By: hans at parse dot nl
Status: Open
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.2.4RC1
New Comment:
A little more explanation fyi: The problem is that DOCUMENT_ROOT is
always set to the configured document root of the default host or the
vhost, even when calling scripts from a userdir. This is not just in
Lighttpd/FastCGI, also f.e. in Apache setups. In my testcase
DOCUMENT_ROOT is '/var/www/htdocs'.
So if i call http://servername/~hans/info.php/foo/bar , We enter this
bit of code in init_request_info() in sapi/cgi/cgi_main.c:
---
/* figure out docroot
SCRIPT_FILENAME minus SCRIPT_NAME
*/
if (env_document_root)
{
int l = strlen(env_document_root);
int path_translated_len = 0;
char *path_translated = NULL;
if (l && env_document_root[l - 1] == '/') {
--l;
}
/* we have docroot, so we should have:
* DOCUMENT_ROOT=/docroot
* SCRIPT_FILENAME=/docroot/info.php
*
* SCRIPT_NAME is the portion of the path beyond docroot
*/
env_script_name = pt + l;
---
Since env_document_root is pretty much always set, we enter the if. pt
is '/home/hans/public_html/info.php' at this point (which is correct). l
becomes 15, the strlen of our DOCUMENT_ROOT '/var/www/htdocs'. The
"trailing slash check if loop" is skipped since our docroot doesn't have
a trailing slash. After this, SCRIPT_NAME is set to pt + l. pt being
'/home/hans/public_html/info.php' and l being 15, this results in a
invalid SCRIPT_NAME (and thus a PHP_SELF) of 'ic_html/info.php'.
My patch adds a userdir check to the 'if (env_document_root)', to
prevent from entering this if() with a DOCUMENT_ROOT that doesn't match
the actual docroot of the userdir. The code that follows after this if()
handles the userdir requests perfectly and results in correct
SCRIPT_NAME and PHP_SELF vars.
Previous Comments:
----------------
[2007-08-06 16:11:11] hans at parse dot nl
./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect
--prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php
--with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli
--with-gettext --with-zlib --enable-mbstring --enable-sockets
--enable-sysvsem --enable-sysvshm --enable-debug=no
Direct link to my patch against php-5.2.3 on lighttpd Trac:
http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff
[2007-08-06 15:45:15] [EMAIL PROTECTED]
What was the configure line used to configure PHP?
----------------
[2007-08-06 08:30:01] hans at parse dot nl
Yes, problem found initially in 5.2.3 but i tested and confirmed with
5.2.4RC1 before submitting this bug report.
Turning off cgi.fix_pathinfo results in a "No input file specified."
message (url being http://servername/~hans/info.php/foo/bar).
[2007-08-04 14:14:24] [EMAIL PROTECTED]
Also, what is the result if cgi.fix_pathinfo = 0 ?
[2007-08-04 14:13:36] [EMAIL PROTECTED]
And you are really using 5.2.4RC1?
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
#42198 [Fbk->Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
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: ./configure --enable-cgi --enable-fastcgi --enable-force-cgi-redirect --prefix=/usr --sysconfdir=/etc --with-config-file-path=/etc/php --with-openssl --with-bz2 --with-gd --with-mysql --with-mysqli --with-gettext --with-zlib --enable-mbstring --enable-sockets --enable-sysvsem --enable-sysvshm --enable-debug=no Direct link to my patch against php-5.2.3 on lighttpd Trac: http://trac.lighttpd.net/trac/attachment/ticket/405/cgi_main.diff Previous Comments: [2007-08-06 15:45:15] [EMAIL PROTECTED] What was the configure line used to configure PHP? [2007-08-06 08:30:01] hans at parse dot nl Yes, problem found initially in 5.2.3 but i tested and confirmed with 5.2.4RC1 before submitting this bug report. Turning off cgi.fix_pathinfo results in a "No input file specified." message (url being http://servername/~hans/info.php/foo/bar). [2007-08-04 14:14:24] [EMAIL PROTECTED] Also, what is the result if cgi.fix_pathinfo = 0 ? [2007-08-04 14:13:36] [EMAIL PROTECTED] And you are really using 5.2.4RC1? [2007-08-03 10:24:23] hans at parse dot nl Description: Problem is as described in Lighttpd ticket #405 at http://trac.lighttpd.net/trac/ticket/405 Using Lighttpd with PHP-5.2.4RC1 as FastCGI. cgi.fix_pathinfo = 1 in php.ini Accessing a script in a userdir without path info works fine: http://servername/~hans/info.php SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = '/~hans/info.php' PHP_SELF = '/~hans/info.php' Accessing the same script with some added path info: http://servername/~hans/info.php/foo/bar PATH_INFO = '/foo/bar' SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = 'ic_html/info.php' PHP_SELF = 'ic_html/info.php' I have posted a working patch which adds a userdir check in cgi_main.c in the Lighttpd ticket mentioned. -- Edit this bug report at http://bugs.php.net/?id=42198&edit=1
#42198 [Fbk->Opn]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
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: Yes, problem found initially in 5.2.3 but i tested and confirmed with 5.2.4RC1 before submitting this bug report. Turning off cgi.fix_pathinfo results in a "No input file specified." message (url being http://servername/~hans/info.php/foo/bar). Previous Comments: [2007-08-04 14:14:24] [EMAIL PROTECTED] Also, what is the result if cgi.fix_pathinfo = 0 ? [2007-08-04 14:13:36] [EMAIL PROTECTED] And you are really using 5.2.4RC1? [2007-08-03 10:24:23] hans at parse dot nl Description: Problem is as described in Lighttpd ticket #405 at http://trac.lighttpd.net/trac/ticket/405 Using Lighttpd with PHP-5.2.4RC1 as FastCGI. cgi.fix_pathinfo = 1 in php.ini Accessing a script in a userdir without path info works fine: http://servername/~hans/info.php SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = '/~hans/info.php' PHP_SELF = '/~hans/info.php' Accessing the same script with some added path info: http://servername/~hans/info.php/foo/bar PATH_INFO = '/foo/bar' SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = 'ic_html/info.php' PHP_SELF = 'ic_html/info.php' I have posted a working patch which adds a userdir check in cgi_main.c in the Lighttpd ticket mentioned. -- Edit this bug report at http://bugs.php.net/?id=42198&edit=1
#42198 [NEW]: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO
From: hans at parse dot nl Operating system: Linux PHP version: 5.2.4RC1 PHP Bug Type: CGI related Bug description: SCRIPT_NAME and PHP_SELF truncated when inside a userdir and using PATH_INFO Description: Problem is as described in Lighttpd ticket #405 at http://trac.lighttpd.net/trac/ticket/405 Using Lighttpd with PHP-5.2.4RC1 as FastCGI. cgi.fix_pathinfo = 1 in php.ini Accessing a script in a userdir without path info works fine: http://servername/~hans/info.php SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = '/~hans/info.php' PHP_SELF = '/~hans/info.php' Accessing the same script with some added path info: http://servername/~hans/info.php/foo/bar PATH_INFO = '/foo/bar' SCRIPT_FILENAME = '/home/hans/public_html/info.php' SCRIPT_NAME = 'ic_html/info.php' PHP_SELF = 'ic_html/info.php' I have posted a working patch which adds a userdir check in cgi_main.c in the Lighttpd ticket mentioned. -- Edit bug report at http://bugs.php.net/?id=42198&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42198&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42198&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42198&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42198&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42198&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42198&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42198&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42198&r=support Expected behavior:http://bugs.php.net/fix.php?id=42198&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42198&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42198&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42198&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42198&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42198&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42198&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42198&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42198&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42198&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42198&r=mysqlcfg
