#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: phpbug-032603 at smayw dot nask dot com Reported By: ulysses at mail dot fitan dot com dot tw Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: This bug is still present in the most current (26 Mar 2003) CVS that claims to be 4.3.2RC To recap - 4.3.2RC as CGI does NOT have the variable PATH_TRANSLATED defined, 4.3.1 as CGI for example does. Is this on purpouse or did the fix get lost somewhere? Previous Comments: [2003-01-26 19:32:31] ulysses at mail dot fitan dot com dot tw Thank you. [2003-01-25 16:32:38] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. PATH_INFO and PATH_TRANSLATED conform to the CGI spec in PHP 4.3. For linux (and possibly other platforms) a fix was requried which is now in CVS (fixes PHP_SELF also). The fix in CVS also creates ORIG_PATH_INFO and ORIG_PATH_TRANSLATED so you can easily fix scripts dependent on the previous incorrect variables. ISAPI has always had broken PATH_INFO/PATH_TRANSLATED, and this was not changed in 4.3, but will be fixed for 5.0. [2003-01-20 21:32:31] ulysses at mail dot fitan dot com dot tw Well, cgi.fix_pathinfo does not completely solve this problem. By adding this line to php.ini, $PATH_INFO is presented only in CGI mode. However, it is still missing in ISAPI mode. It is indeed a bug, or else they should put a warning message in 4.30 press release or installation document. [2003-01-20 18:55:05] andrey at cherezov dot koenig dot su See bug http://bugs.php.net/bug.php?id=21716 Thanks to Milky! Use cgi.fix_pathinfo=0 in 4.3.0 php.ini to solve this problem. [2003-01-18 07:02:44] andrey at cherezov dot koenig dot su Compare these PhpInfo() outputs: http://php430.eserv.ru/php_info.php/path/info?query http://php423.eserv.ru/php_info.php/path/info?query Same web-server, same php.ini, very different environment variables! (of course, web-server pass the same variables, but 4.3.0 damages them! ;) PATH_INFO disappears in 4.3.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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: Thank you. Previous Comments: [2003-01-25 16:32:38] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. PATH_INFO and PATH_TRANSLATED conform to the CGI spec in PHP 4.3. For linux (and possibly other platforms) a fix was requried which is now in CVS (fixes PHP_SELF also). The fix in CVS also creates ORIG_PATH_INFO and ORIG_PATH_TRANSLATED so you can easily fix scripts dependent on the previous incorrect variables. ISAPI has always had broken PATH_INFO/PATH_TRANSLATED, and this was not changed in 4.3, but will be fixed for 5.0. [2003-01-20 21:32:31] [EMAIL PROTECTED] Well, cgi.fix_pathinfo does not completely solve this problem. By adding this line to php.ini, $PATH_INFO is presented only in CGI mode. However, it is still missing in ISAPI mode. It is indeed a bug, or else they should put a warning message in 4.30 press release or installation document. [2003-01-20 18:55:05] [EMAIL PROTECTED] See bug http://bugs.php.net/bug.php?id=21716 Thanks to Milky! Use cgi.fix_pathinfo=0 in 4.3.0 php.ini to solve this problem. [2003-01-18 07:02:44] [EMAIL PROTECTED] Compare these PhpInfo() outputs: http://php430.eserv.ru/php_info.php/path/info?query http://php423.eserv.ru/php_info.php/path/info?query Same web-server, same php.ini, very different environment variables! (of course, web-server pass the same variables, but 4.3.0 damages them! ;) PATH_INFO disappears in 4.3.0 :( [2003-01-18 06:35:03] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string You may try this URL url on Win32 web-server with PHP 4.3.0 as CGI and YOU WILL SEE - for this URL PHP will not show PATH_INFO variable, passed to it by web-server! Web-server pass PATH_INFO=/path/info (for this URL), but PhpInfo() in PHP 4.3.0 will NOT show PATH_INFO in the list! All old 4.2.x versions works OK with this case, and previous 4.3.0-dev too, but in 4.3.0 just drop PATH_INFO in any case. This is definitely 4.3.0 BUG. 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: See bug http://bugs.php.net/bug.php?id=21716 Thanks to Milky! Use cgi.fix_pathinfo=0 in 4.3.0 php.ini to solve this problem. Previous Comments: [2003-01-18 07:02:44] [EMAIL PROTECTED] Compare these PhpInfo() outputs: http://php430.eserv.ru/php_info.php/path/info?query http://php423.eserv.ru/php_info.php/path/info?query Same web-server, same php.ini, very different environment variables! (of course, web-server pass the same variables, but 4.3.0 damages them! ;) PATH_INFO disappears in 4.3.0 :( [2003-01-18 06:35:03] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string You may try this URL url on Win32 web-server with PHP 4.3.0 as CGI and YOU WILL SEE - for this URL PHP will not show PATH_INFO variable, passed to it by web-server! Web-server pass PATH_INFO=/path/info (for this URL), but PhpInfo() in PHP 4.3.0 will NOT show PATH_INFO in the list! All old 4.2.x versions works OK with this case, and previous 4.3.0-dev too, but in 4.3.0 just drop PATH_INFO in any case. This is definitely 4.3.0 BUG. [2003-01-13 11:26:28] [EMAIL PROTECTED] register globals has nothing to do with this. For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php, and use SCRIPT_FILENAME if you need to get the full path to script_name.php [2003-01-13 06:15:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: [EMAIL PROTECTED] wrote: For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string You may try this URL url on Win32 web-server with PHP 4.3.0 as CGI and YOU WILL SEE - for this URL PHP will not show PATH_INFO variable, passed to it by web-server! Web-server pass PATH_INFO=/path/info (for this URL), but PhpInfo() in PHP 4.3.0 will NOT show PATH_INFO in the list! All old 4.2.x versions works OK with this case, and previous 4.3.0-dev too, but in 4.3.0 just drop PATH_INFO in any case. This is definitely 4.3.0 BUG. Previous Comments: [2003-01-13 11:26:28] [EMAIL PROTECTED] register globals has nothing to do with this. For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php, and use SCRIPT_FILENAME if you need to get the full path to script_name.php [2003-01-13 06:15:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn [2003-01-11 12:15:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: Compare these PhpInfo() outputs: http://php430.eserv.ru/php_info.php/path/info?query http://php423.eserv.ru/php_info.php/path/info?query Same web-server, same php.ini, very different environment variables! (of course, web-server pass the same variables, but 4.3.0 damages them! ;) PATH_INFO disappears in 4.3.0 :( Previous Comments: [2003-01-18 06:35:03] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string You may try this URL url on Win32 web-server with PHP 4.3.0 as CGI and YOU WILL SEE - for this URL PHP will not show PATH_INFO variable, passed to it by web-server! Web-server pass PATH_INFO=/path/info (for this URL), but PhpInfo() in PHP 4.3.0 will NOT show PATH_INFO in the list! All old 4.2.x versions works OK with this case, and previous 4.3.0-dev too, but in 4.3.0 just drop PATH_INFO in any case. This is definitely 4.3.0 BUG. [2003-01-13 11:26:28] [EMAIL PROTECTED] register globals has nothing to do with this. For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php, and use SCRIPT_FILENAME if you need to get the full path to script_name.php [2003-01-13 06:15:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn [2003-01-11 12:15:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn Previous Comments: [2003-01-11 12:15:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. [2003-01-10 21:54:37] [EMAIL PROTECTED] Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? [2003-01-10 21:01:46] [EMAIL PROTECTED] Environment variable PATH_INFO disappeared in PHP4.30, which is presented in 4.1x and 4.2x. I know that I can use PHP_SELF instead, but my old codes now having problems. -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: register globals has nothing to do with this. For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php, and use SCRIPT_FILENAME if you need to get the full path to script_name.php Previous Comments: [2003-01-13 06:15:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn [2003-01-11 12:15:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. [2003-01-10 21:54:37] [EMAIL PROTECTED] Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
