|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21261 $_SERVER['PHP_SELF'] gives wrong info
Submitted: 2002-12-28 22:05 UTC Modified: 2003-01-25 16:06 UTC
Avg. Score:5.0 ± 0.0
Reproduced:14 of 14 (100.0%)
Same Version:8 (57.1%)
Same OS:7 (50.0%)
From: undream at yifan dot net Assigned: shane (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.0 OS: linux 2.4.18 - slack 8.1
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: undream at yifan dot net
New email:
PHP Version: OS:


 [2002-12-28 22:05 UTC] undream at yifan dot net
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)  


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-12-28 22:51 UTC]
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.
 [2002-12-29 14:05 UTC] undream at yifan dot net
A strace dump for the following page content:     
echo $_SERVER['PHP_SELF'];     
called from url: http://localhost/test.php can be found    
The PHP_SELF result for that one was :PHP/4.3.0 
I also have a phpinfo dump of my setup at: 
This last one was called using http://localhost/env.php 
url. As you can see, the PHP_SELF result is equally weird.
 [2002-12-29 19:51 UTC]
I have a theory, but I need you to run one more test:

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


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"
 [2002-12-30 10:59 UTC] undream at yifan dot net
'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 
-----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 
HTTP_ACCEPT = text/*, image/jpeg, image/png, image/*, */* 
SCRIPT_NAME = /cgi-bin/test-cgi 
I also posted the phpinfo() fron php cgi 4.2.3 at 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)
 [2002-12-30 20:21 UTC] tapken at engter dot de
I have a similar problem. It is discribed in

The result of set cat be viewed on
 [2002-12-30 20:21 UTC]
Probable cause found.... Checking with submitter of prior patch.
 [2002-12-31 01:21 UTC] shane at caraveo dot com
Send me the pertinent lines out of httpd.conf that you have used to configure php so I can test with the same settings.
 [2003-01-01 11:21 UTC] undream at yifan dot net
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 
 [2003-01-02 10:54 UTC] tapken at engter dot de
I'm using php with cgiwrap.

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/
 [2003-01-05 21:58 UTC]
The patch at

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

 [2003-01-06 11:06 UTC] undream at yifan dot net
Negative. Patch not only did not work (I applied it to 
current 4.3.0) but I now no longer have a 
So $_SERVER['PHP_SELF'] remains corrupted and 
$_SERVER['PATH_TRANSLATED'] gives some kind of udefined 
 [2003-01-07 00:42 UTC] 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?
 [2003-01-07 13:27 UTC] tapken at engter dot de
Same for me, your patch seems to have no affect.

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

Environment Variables:
      SCRIPT_NAME: '/phpinfo.php'
        PATH_INFO: '/phpinfo.php'
      REMOTE_ADDR: ''

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

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.
 [2003-01-07 13:30 UTC] tapken at engter dot de
There is no space in SCRIPT_NAME on my localhost, this was an copy&paste-error. But the "I" at the end exists.
 [2003-01-09 14:57 UTC] tapken at engter dot de
Quick & Dirty PHP-Based workaround:

Put this code in a file and add it to auto_prepend_file-directive in php.ini:
// Small Workaround for a bug in PHP 4.3.0/cgi
// See for details



Works fine for me... If PHP is used as CLI it may be neccessary to check current mode before running this code.
 [2003-01-13 11:41 UTC] daniel dot gorski at develnet dot org
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  (PHP4 CGI)  (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
 [2003-01-17 06:36 UTC] tapken at engter dot de
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...

// Small Workaround for a bug in PHP 4.3.0/cgi
// See for details

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

 [2003-01-25 16:06 UTC]
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
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the 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:
 [2003-02-07 16:25 UTC] russ at iris dot washington dot edu
Tilde expansion in URL has same problem on Solaris.

I was able to use the provided workaround:
    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:


--Thank you to whoever came up with that workaround above.
 [2003-04-17 07:38 UTC] adamski at echtzeit dot com
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 :)
 [2003-04-23 21:27 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.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri May 20 01:05:45 2022 UTC