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?

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.

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.

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

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.

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

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.

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 :(

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.

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.

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.

Thank you.

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?

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.

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

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