#27375 [Com]: $DOCUMENT_ROOT sometimes empty when register_globals=on

ID: 27375 Comment by: rob at realmsolutions dot com Reported By: oliver at update dot ch Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.3. New Comment: OK, this was not fixed by the latest snapshot, which I just tried, and still get the same results... Please reopen this bug, its not bogus. Here's more info, let me know if you need anything else. I've installed apache 2.0.48 with the latest php 4.3.4 snapshot. I always have register globals off in both php.ini and defined that way in the vhost too. I always refer to the variable as $_SERVER["DOCUMENT_ROOT"]. I have about 80 virtualhosts set up, and I've had a wide variety of them have the DOCUMENT_ROOT var get the wrong pathname. But the weird thing is that when the pathname is wrong, its always the same path from another vhost. The wierd thing is, that particular vhost doesnt really stand out in any obvious way... its not the first vhost in the config, its not the last either... kinda in the middle. its not alphabetically first or last, its not the site that gets the most traffic, nor the least. The only thing unusual about it is that it has alot of complex mod_rewriting going on, however, its not the only vhost that uses complex mod_rewriting either.... so I'm kinda stumped as to why it always seems to have the _same_wrong_path_ in the DOCUMENT_ROOT variable! If you want or need any more info, please just ask or tell me what to do! Previous Comments: ------------------------------------------------------------------------ [2004-03-07 03:22:29] rob at realmsolutions dot com OK, I've got similar but even weirder problem. I just installed the latest production releases of apache2/php and now I occasionally get _wrong_ values in the DOCUMENT_ROOT variable. Instead of containing the pathname of the current virtual host, it sometimes contains the pathname of a different virtual host also configured on this server! There is definitely some problem here, if I click from vhost site to vhost site, I can get these errors repeatedly. Since I'm including files based on the DOCUMENT_ROOT, it manifests itself as an error that looks like this: Warning: main(/home/wrongwebsite/www/includes/functions_generic.php): failed to open stream: No such file or directory in /home/correctwebsite/www/includes/config.php on line 47 In this example its _should_ be including the file functions_generic from "correctwebsite", not "wrongwebsite" After the first instance of this error, it seems to go away until I switch to another website, where it may or may not happen again... FYI, here are the flags set in my virtualhost: php_admin_flag engine on php_admin_flag safe_mode off php_admin_flag register_globals off php_admin_flag display_errors on ------------------------------------------------------------------------ [2004-02-25 06:17:12] sniper@php.net If you had bothered searching the bug database first you would have find couple of dozen similar reports. And also that this is most likely FIXED in CVS. (get stable snapshot from http://snaps.php.net/ ) ------------------------------------------------------------------------ [2004-02-25 02:04:35] oliver at update dot ch Sorry about that. I'm not the pro on stuff like this. But I try again: Configuration: -------------- './configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs' '--with-config-file-path=/etc/httpd2' '--prefix=/opt/ php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg- dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with- freetype-dir=/usr' '--enable-gd-native-ttf' '--enable- debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable- track-vars=yes' '--disable-cgi' '--enable-calendar' '-- with-ttf' '--with-imap' '--with-ft' '--with-xml' '-- with-mhash' '--with-mcrypt' '--with-bcmath' '--with- snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp- compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with- zlib' '--enable-trans-sid' '--with-openssl' '--with- wddx' '--with-crack' '--with-kerberos' '--with-gettext' Reproduce code: --------------- register_globals: "<?=ini_get('register_globals')?>" $GLOBALS["DOCUMENT_ROOT"] = "<? =$GLOBALS["DOCUMENT_ROOT"];?> $DOCUMENT_ROOT: "<?=$DOCUMENT_ROOT?>" $_SERVER["DOCUMENT_ROOT"]: "<?=$_SERVER[ 'DOCUMENT_ROOT' ]?>" Expected result: ---------------- register_globals: "1" $GLOBALS["DOCUMENT_ROOT"] = "/home/www/ $DOCUMENT_ROOT: "/home/www/" $_SERVER["DOCUMENT_ROOT"]: "/home/www/" Result (tested on 02/24/04): -------------- register_globals: "1" $GLOBALS["DOCUMENT_ROOT"] = "" $DOCUMENT_ROOT: "" $_SERVER["DOCUMENT_ROOT"]: "/home/www/" PHP-Version is 4.3.3. The thing is, that I couldn't reproduce the result today (02/25). So I guess, you can really let vanish this report. Thanks for the help anyway. ------------------------------------------------------------------------ [2004-02-24 16:57:50] sniper@php.net Second try. (If I have to ask these same things for the 3rd time, this bug report will vanish mysteriously..) 1. How did you configure Apache? (configure line used) 2. What MPM are you using with Apache? 3. What is register_globals set to WHEN this happens? (put var_dump(ini_get("register_globals")); in the beginning of your script, see bug #24253 what a nice short test script looks like) 4. Are you sure there aren't any .htaccess files or vhosts setting register_globals to something else? Or setting any other php.ini options? (using php_value, php_admin_value, php_flag or php_admin_flag directives) 5. How was PHP configured into Apache? (as module or CGI binary??) ------------------------------------------------------------------------ [2004-02-24 12:59:58] oliver at update dot ch register_globals is always set on. register_globals is set to on in the php.ini file. SERVER_SOFTWARE: Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.6.1 mod_ssl/2.0.47 OpenSSL/0.9.6c DAV/2 FrontPain/5.0.0.0 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27375 -- Edit this bug report at http://bugs.php.net/?id=27375&edit=1