php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #3205 $PHP_SELF is getting set incorrectly when force-cgi-redirect not set in CGI
Submitted: 2000-01-13 15:59 UTC Modified: 2005-03-30 09:03 UTC
From: ra9104 at email dot sps dot mot dot com Assigned:
Status: Wont fix Package: Misbehaving function
PHP Version: 3.0.14 OS: Solaris 2.6
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ra9104 at email dot sps dot mot dot com
New email:
PHP Version: OS:

 

 [2000-01-13 15:59 UTC] ra9104 at email dot sps dot mot dot com 
I am running the CGI binary under Netscape Enterprise Server 3.5.1E

./configure  --with-gd=/export/home/webber/gd1.3 --with-oracle=/export/home/ora_home --with-ldap=/export/home/webber --with-mysql=/usr/local/mysql --enable-track-vars --enable-discard-path --with-imap=/export/home/webber

Upgraded from 3.0.12 to 3.0.14 and found the following behavior to change:

When accessing a URL such as "http://www.server.nam/dir/" $PHP_SELF would be set to /dir//dir/index.phtml but when accessing the same script by accessing "http://www.server.nam/dir/index.phtml" $PHP_SELF would be set correctly to /dir/index.phtml

Noticed that when calling the first URL that $SCRIPT_NAME would be set to the directory of the script but not have the actual filename, in main.c if $SCRIPT_NAME is set and does not contain the same value as $PATH_INFO then they will be concatenated and passed into $PHP_SELF, this is what was causing the error.

I modified main.c to not use GLOBAL(request_info).script_name when assembling the value for $PHP_SELF and it worked fine.

Used an index.php3 script with <? phpinfo(); ?> in it to check the behavior.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-30 09:03 UTC] sniper@php.net 
We are sorry, but we can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Of course PHP 4 will continue to be supported for the
forseeable future.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 30 14:01:28 2024 UTC