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

go to bug id or search bugs for

Bug #15196 PHP_*_VARS have disappeared, even though track_vars is on
Submitted: 2002-01-24 01:22 UTC Modified: 2002-01-24 02:31 UTC
From: doktor1 at earthlink dot net Assigned:
Status: Not a bug Package: Variables related
PHP Version: 4.1.1 OS: Linux 2.4
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2002-01-24 01:22 UTC] doktor1 at earthlink dot net 
I fetched the latest Apache and PHP earlier this week and built everything from scratch, to find that an auth routine I'd written a long time ago was suddenly acting as though it wasn't seeing HTTP_POST_VARS. I stuck in a phpinfo() line to see what the deal was, and sure enough, no HTTP_*_VARS!

For simplicity, I created a file called test.php, which contains just one statement - phpinfo();.

If I call this file as 'test.php?blah=asdf', I can look high and low, and I will not find HTTP_GET_VARS, HTTP_POST_VARS, etc. I do see _GET, etc., but... I don't want to do a full source review of PHPBB and other stuff. :(

Here're the configure options according to phpinfo()...

'./configure' '--sysconfdir=/etc/php' '--with-apache=../apache_1.3.22' '-- with-config-file-path=/etc/php' '--with-zlib' '--enable-bcmath' '--with-jpeg- dir=/usr' '--with-gd=/usr' '--enable-gd-native-ttf' '--with-png-dir=/usr' '-- with-mysql' '--enable-track-vars'

Then in /etc/php/php.ini, just to be safe, I have this...
; Note - track_vars is ALWAYS enabled as of PHP 4.0.3
track_vars = On

Then there's the variables order...
variables_order = "GPCES"

I also tried setting the order to EGPCS, but I don't think this really matters.

I apologize if there is something foolish I've overlooked, but php.ini doesn't appear to contain any way for me to turn off $HTTP_*_VARS, other than maybe saying track_vars = Off.

P.S. I have tried this with register_globals on and off.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-24 01:30 UTC] derick@php.net 
They are not gone, they have new aliases which are shown in the phpinfo() output. Please read:
It's also advisable that your swich overe to this new mechanism, as it can make your scripts more secure (in combination with turning off register_globals).

Derick
 [2002-01-24 01:40 UTC] doktor1 at earthlink dot net 
"They are not gone, they have new aliases which are shown in the
phpinfo() output. Please read:"

Did you mean to put in a URL after "Please read:"? Anyway, is there a way to force PHP to put in the old HTTP_*_VARS rather than forcing everyone to migrate to $_GET etc.?

"It's also advisable that your swich overe to this new mechanism, as it
can make your scripts more secure (in combination with turning off
register_globals)."

I don't mind doing that, and in fact I mean to do so with my own code now that I've seen it (I like that better actually), but I have stuff (like PHPBB) which is designed to expect HTTP_POST_VARS.
 [2002-01-24 01:49 UTC] edejanu at route66 dot ro 
You can still access the old vars, Derick also told you
that they are not gone.
Do:
<?php print_r($GLOBALS); ?> 
and you will see. Or
<?php print_r($HTTP_POST_VARS); ?>

Emanuel
 [2002-01-24 02:06 UTC] doktor1 at earthlink dot net 
Oh... OK. I get it now. :)

However, it is a little disconcerting to have them not show up in phpinfo() any longer. Just my 2 cents.
 [2002-01-24 02:31 UTC] derick@php.net 
The URL I wanted to post:
http://www.php.net/release_4_1_0.php

And both showing the arrays $_POST and $HTTP_POST_VARS in phpinfo(), while they contain the same thing doesn't seem very useful to me...

Derick
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 07:01:29 2024 UTC