A call to http://localhost/env.php  with env.php  
containing a phpinfo() call returns this for  
$_SERVER['PHP_SELF'] = ocs/env.php  
 
I have no idea what 'ocs' is. This is run on a Konqueror 
3.1 browser. PHP is ran as CGI. Previous php (4.2.3) 
compiled using the _exact_ same setup gives the correct 
info (localhost/env.php)  

1) What webserver are you running? (and what version?)

2) Since you are running as a CGI can you please do an strace on this
page?

Example (correct the file paths as necessary, you may need to install
strace first):

strace /usr/local/bin/php -f /var/www/env.php 2> /var/www/bug-21261.log

Provide a URL to this strace so that the problem can be further
diagnosed.

A strace dump for the following page content:     
<?php    
echo $_SERVER['PHP_SELF'];     
?>     
called from url: http://localhost/test.php can be found    
at: http://www.undream.com/php/bug-21261.log   
The PHP_SELF result for that one was :PHP/4.3.0 
 
I also have a phpinfo dump of my setup at:  
http://www.undream.com/php/env.html 
This last one was called using http://localhost/env.php 
url. As you can see, the PHP_SELF result is equally weird.

I have a theory, but I need you to run one more test:

1) Create a CGI shell script "/var/www/htdocs/shenv.sh" with the
following content:

#!/bin/sh
set

2) Be sure to chmod it so that it can be executed by the webserver then
browse to it (i.e.: http://localhost/shenv.php )

Post the results here.

My theory is that Apache is not setting the CGI environment variables
"SCRIPT_NAME" or "PATH_INFO" correctly.  But I can at least tell you one
thing for sure...  The "ocs" in "ocs/env.php" is comming from the last
three characters in the file's true path "/var/www/htdocs/env.php"

'set' alone does not give PATH_INFO but I explicitly 
called a few vars. Note that I had to run it from the 
cgi-bin dir, but they were the same for php 4.3.0 and 
4.2.3: 
-----CGI/1.0 test script with cgi php 4.3.0 OR 4.2.3----- 
 
SERVER_SOFTWARE = Apache/1.3.27 (Unix) 
SERVER_NAME = localhost.localdomain 
GATEWAY_INTERFACE = CGI/1.1 
SERVER_PROTOCOL = HTTP/1.1 
SERVER_PORT = 80 
REQUEST_METHOD = GET 
HTTP_ACCEPT = text/*, image/jpeg, image/png, image/*, */* 
PATH_INFO =  
PATH_TRANSLATED =  
SCRIPT_NAME = /cgi-bin/test-cgi 
QUERY_STRING =  
REMOTE_HOST = 
REMOTE_ADDR = 127.0.0.1 
REMOTE_USER = 
AUTH_TYPE = 
CONTENT_TYPE = 
CONTENT_LENGTH = 
 
I also posted the phpinfo() fron php cgi 4.2.3 at 
http://www.undream.com/php/env-4.2.3.html. The php_self is 
correct there. Nothing else has changed. 
I also played around with calling php_info() from various 
directories.  Sometimes pieces of the php_self path are 
hopped, sometimes it is not even set. It is very 
consistent. I did not notice any pattern (i.e chopping off 
the first x letters everytime)

I have a similar problem. It is discribed in
http://bugs.php.net/bug.php?id=21301

The result of set cat be viewed on
http://www.engter.de/shenv.php

Probable cause found.... Checking with submitter of prior patch.

Send me the pertinent lines out of httpd.conf that you have used to
configure php so I can test with the same settings.

Are you talking about this? 
 
ScriptAlias /cgi/ /var/www/htdcos/cgi/ 
Action application/x-httpd-php  /cgi/php 
AddType application/x-httpd-php .php 
 
I can also post my ini and my configure script though you 
can probably get that info from the env.html I posted 
earlier.

I'm using php with cgiwrap. 
http://cgiwrap.unixtools.org/

I added two small patches as described in Bug #21301 but i don't know if
they work with current cvs version.

In httpd.conf:

AddHandler php-cgiwrap .php
Action php-cgiwrap /cgiwrapper/php-cgiwrap/<USER>
ScriptAlias /cgiwrapper/ /usr/local/cgiwrap/

The patch at
http://www.caraveo.com/php/cgi.patch

Should fix this problem.  Please try this and let me know.  It's against
cvs HEAD from today.

Negative. Patch not only did not work (I applied it to 
current 4.3.0) but I now no longer have a 
$_SERVER['PATH_TRANSLATED'] variable . 
So $_SERVER['PHP_SELF'] remains corrupted and 
$_SERVER['PATH_TRANSLATED'] gives some kind of udefined 
error. 
Joshua

undream@yifan.net: email me your httpd.conf, php.ini and the test script
you use.  You can remove anything from the files that are private. 
Also, as per spec PATH_TRANSLATED will be empty unless you have
PATH_INFO, which is path data *after* the script in a url:
http://host/script.php/path/info?query-string
The only thing I'm concerned about is the garbled PHP_SELF.  PHP_SELF is
the same as SCRIPT_NAME, is SCRIPT_NAME also garbled?

Same for me, your patch seems to have no affect.

I checked the debugging output from cgiwrap which says:
[...]
Fixing Environment Variables.

Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/phpinfo.php'
  SCRIPT_FILENAME: '<DOCUMENT_ROOT>/phpinfo.php'
     REDIRECT_URL: '<NULL>'
        PATH_INFO: '/phpinfo.php'
  PATH_TRANSLATED: '<DOCUMENT_ROOT>/phpinfo.php'
      REMOTE_USER: '<NULL>'
      REMOTE_HOST: '<NULL>'
      REMOTE_ADDR: '217.4.137.70'
[...]

Seems to be ok?! But PHP_SELF has no value.

On my localhost PHP 4.3/CGI works with cgiwrap. The same paragraph with
this machine:
[...]
Fixing Environment Variables. 

Environment Variables: 
     QUERY_STRING: '' 
      SCRIPT_NAME: '/php/ phpinfo.phpI' 
  SCRIPT_FILENAME: '<DOCUMENT_ROOT>/php/phpinfo.php'    
     REDIRECT_URL: '' 
        PATH_INFO: '/php/phpinfo.php' 
  PATH_TRANSLATED: '<DOCUMENT_ROOT>/php/phpinfo.php'     
      REMOTE_USER: '' 
      REMOTE_HOST: '' 
     REMOTE_ADDR: '192.168.23.2'
[...]

In this case, script_name is broken for some reason (don't ask me why, i
didn't find out). But PHP_SELF has the correct value! On both server
SCRIPT_NAME isn't listed in the phpinfo()-Output.

Hope this will help.

There is no space in SCRIPT_NAME on my localhost, this was an
copy&paste-error. But the "I" at the end exists.

Quick & Dirty PHP-Based workaround:

Put this code in a file and add it to auto_prepend_file-directive in
php.ini:
-snip----------------------------------------
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
                                 strlen($_SERVER['DOCUMENT_ROOT']));

$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip------------------------------------

Works fine for me... If PHP is used as CLI it may be neccessary to check
current mode before running this code.

That (or similar) urgent problem occurs here too. PHP versions before
mid december were not affected IMO.

At first today I've checked out the "php4" and "php5" modules from CVS,
configured, and build them. After installation of the CGI binaries I
detected a problem with $_SERVER['PHP_SELF']:

a) the PHP4 version shows "no value"
b) the PHP5 version shows illegal characters, cut off strings with low
ASCII values etc. Depending on the namebased vhost name the value of
PHP_SELF looks like "ind##" instead of "index.php" ("#" should represent
low ASCII chars, which are shown as boxes here) of just "5" which is
definitely the last char of "index.php5". Short: looks like a pointer on
a string array is bent somewhere.

The problem insist with and without '--enable-force-cgi-redirect' in
both versions. As an example you may want to take a look at

  http://daniel-gorski.de/index.php4  (PHP4 CGI)
  http://daniel-gorski.de/index.php5  (PHP5 CGI)

and compare the values of $_SERVER['PHP_SELF']. Additionally the PHP5
version has a strange "Zend Extension" date: 90021012. OTOH this value
seems to be correct in the PHP4 version.

The operating system is Linux (RedHat 6.2).

I would appreciate to see this bug solved as soon as possible, because
this is a dramatic show stopper for a few ZE2 applications I am
developing & running.

What required information can I provide to help to solve this problem?

regards dtg

Sorry, my PHP-Based Workaround seems to be buggy in some cases, too...
Here is a quick & dirty bugfix for the quick & dirty workaround :-)

Btw, it would be nice if the bug is fixed in PHP 4.3.1...

-snip----------------------------------------
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
                                 strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
    $_SERVER['SCRIPT_NAME'] = substr($_SERVER['SCRIPT_NAME'], 1);
}

$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip------------------------------------

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.

This is now fixed in cvs:
4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12
5.0: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.208

Tilde expansion in URL has same problem on Solaris.

I was able to use the provided workaround:
    $_SERVER['SCRIPT_NAME'] =
    substr($_SERVER['PATH_TRANSLATED'],
       strlen($_SERVER['DOCUMENT_ROOT']));
    if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
       $_SERVER['SCRIPT_NAME'] =
            substr($_SERVER['SCRIPT_NAME'], 1);
    }
to fix the same problem (invalid PHP_SELF) on Solaris 2.7
Sparc, PHP 4.3.0 (fresh).

Simply doing phpinfo(); and then appending the value of
PHP_SELF onto an 'ls ' statement yielded "no such file".

The file did not exist:
$ ls /~russ/tryseed/showSeed.phtml
/~russ/tryseed/showSeed.phtml: No such file or directory

What I can contribute here is this: I was running out
of a "pubic_html" subdirectory off of ~russ (above), and 
the URL typed into IE 5.2 (Mac OS X) was:

"http://hostname/~russ/tryseed/showSeed.html"

--Thank you to whoever came up with that workaround above.

I just tried PHP 4.3.1 as cgi on SUSE 6.4/Apache 1.3.19 and the bug is
still there. The workaround helps though :)

Change your configure statement to '--enable-discard-path' and then PHp
will not try to fopen whatever the PATH_INFO is.