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

go to bug id or search bugs for

Bug #26833 Globals not being defined with 'register_globals On' at random
Submitted: 2004-01-07 19:26 UTC Modified: 2004-01-07 21:00 UTC
From: php at f0e dot net Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 4.3.4 OS: FreeBSD 5.1-RELEASE-p10
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: php at f0e dot net
New email:
PHP Version: OS:

 

 [2004-01-07 19:26 UTC] php at f0e dot net 
Description:
------------
Running Apache/2.0.48 and PHP 4.3.4

PHP configuration:

'./configure' '--with-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-openssl' '--enable-magic-quotes' '--with-zlib' '--with-gd' '--with-freetype-dir' '--with-jpeg-dir' '--enable-gd-native-ttf' '--enable-mime-magic' '--disable-cgi' '--with-mhash'

Changes to the php.ini-dist: 'register_globals = On', 'display_errors = Off', 'log_errors = On'

when I attempt to access (normally) global variables (like $REMOTE_ADDR -- I know I should be using $_SERVER[REMOTE_ADDR] but I cannot force my clients to update all their scripts), maybe 1/10th of the time $REMOTE_ADDR is undefined. $_SERVER[REMOTE_ADDR] is defined all the time however.

I tried moving back to 4.3.3 which still experiences the same problem.

Reproduce code:
---------------
<?
  print "REMOTE_ADDR: '$_SERVER[REMOTE_ADDR]'<br>\n";
  print "REMOTE_ADDR: '$REMOTE_ADDR'";
?>

Expected result:
----------------
REMOTE_ADDR: '127.0.0.1'<br>
REMOTE_ADDR: '127.0.0.1'

Actual result:
--------------
REMOTE_ADDR: '127.0.0.1'<br>
REMOTE_ADDR: ''

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-07 19:49 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And do you by any chance set any php.ini options inside any .htaccess file or in httpd.conf ? (with php_flag / php_value / php_admin_flag / php_admin_value) 

Also, check that register_globals is actually 'On' during execution by adding this to your test script:

var_dump(ini_get('register_globals'));
 [2004-01-07 20:02 UTC] php at f0e dot net 
I added:

var_dump(ini_get('register_globals'));

to the top of the code.. 

When $REMOTE_ADDR was being defined correctly, the first line was 'string(1) "1"'.

After a few more refreshes, $REMOTE_ADDR wasn't defined and the first line was changed to 'string(1) "0"'.

I do not have a .htaccess file in the script's directory or parent directory nor am I setting any php values in the httpd.conf.

I will try the snapshot.

Thanks
 [2004-01-07 20:06 UTC] sniper@php.net 
Are you ABSOLUTELY sure there aren't ANY of those php_* flags used ANYWHERE in your httpd.conf/.htaccess files? (in ANY vhost, etc.)
 [2004-01-07 20:07 UTC] sniper@php.net 
One more thing: How was apache2 configured? (what MPM is used?)
 [2004-01-07 20:26 UTC] php at f0e dot net 
I am positive there are no php_* flags in the httpd.conf, but there is:

php_flag register_globals off
php_value magic_quotes_gpc off

in a .htaccess in a different vhost/directory. 

I configured apache2 with the following:

./configure \
--enable-so \
--enable-ssl \
--enable-rewrite \
--enable-suexec \
--enable-deflate \
--enable-expires \
--enable-headers \
--enable-speling \
--with-suexec-caller=apache \
--with-suexec-docroot=/home \
--with-suexec-logfile=/var/log/suexec_log \
--with-suexec-uidmin=500 \
--with-suexec-gidmin=500

FYI: this error? occurs with the 4.3.5-dev snapshot as well.

Are you thinking that it is apache getting confused and allowing custom php flags from other vhosts interfer? Maybe I'm submitting to the wrong bug tracker :)

Thanks again
 [2004-01-07 21:00 UTC] sniper@php.net 
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Yes, this is same issue as in bug #25753 (no need to add any comments there..unless you can provide a testcase with which this bug can be reproduced reliably everywhere..)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Dec 01 02:00:01 2025 UTC