php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21575 4.2x to 4.3 Compatibility issue
Submitted: 2003-01-10 21:01 UTC Modified: 2003-01-25 16:32 UTC
From: ulysses at mail dot fitan dot com dot tw Assigned:
Status: Closed Package: IIS related
PHP Version: 4.3.0 OS: Windows 2000
Private report: No CVE-ID: None
 [2003-01-10 21:01 UTC] ulysses at mail dot fitan dot com dot tw
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-10 21:54 UTC] pollita@php.net
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-11 06:37 UTC] ulysses at mail dot fitan dot com dot tw
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-11 12:15 UTC] iliaa@php.net
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-13 05:30 UTC] taomyn at hotmail dot com
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-13 06:15 UTC] wez@php.net
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 11:26 UTC] shane at caraveo dot com
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-18 06:35 UTC] andrey at cherezov dot koenig dot su
shane@caraveo.com 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-18 07:02 UTC] 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 :(
 [2003-01-20 18:55 UTC] 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-20 21:32 UTC] 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-25 16:32 UTC] shane@php.net
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-26 19:32 UTC] ulysses at mail dot fitan dot com dot tw
Thank you.
 [2003-03-26 10:38 UTC] phpbug-032603 at smayw dot nask dot com
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?
 [2003-04-23 20:46 UTC] flight553 at yahoo dot com
I can reproduce this bug on Linux running Apache 1.3.27 and PHP 4.3.1 as a cgi at:
http://amulder.modwest.com/inf.php/2/
where sending the last '/2/' to set a PATH_INFO variable actually causes an internal server error.
If you just go to
http://amulder.modwest.com/inf.php
then you will get the normal PHP output.
The contents of that file is just:
#!/usr/local/bin/php-4.3.1
<? 
phpinfo();  
?>

Under PHP 4.2.3 running as a cgi, this problem does not happen, as shown at:
 http://amulder.modwest.com/inf.php/2/
 http://amulder.modwest.com/inf.php
The contents of that file is just:
<? 
phpinfo();  
?>

Therefore, I think this bug is not fixed.
 [2003-04-23 20:48 UTC] flight553 at yahoo dot com
Sorry, the correctly working PHP 4.2.3 phpinfo is at 
http://amulder.modwest.com/inf2.php/2/
and
http://amulder.modwest.com/inf2.php
 [2003-04-23 21:23 UTC] flight553 at yahoo dot com
Change your configure statement to '--enable-discard-path' and then PHp will not try to fopen whatever the PATH_INFO is.

That will fix it. having --disable-discard-path or nothing at all about discard path will get you Internal server errors and wrong behavior
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Nov 13 02:01:30 2019 UTC