Bug #16155 Updated: track_vars doesn't work unless register_globals is also set

From: Date: Wed, 10 Jul 2002 18:09:36 +0000
Subject: Bug #16155 Updated: track_vars doesn't work unless register_globals is also set
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-13758@lists.php.net to get a copy of this message
 ID:               16155
 Updated by:       philip@php.net
 Reported By:      rlm@pricegrabber.com
 Status:           Open
 Bug Type:         PHP options/info functions
 Operating System: RH 7.2
 PHP Version:      4.1.2
 New Comment:

The various places are the: variables_order, register_globals, and
predefind variables manual entries.

track_vars documentation states it's always on as of 4.0.3, do you feel
this should be reworded?  I'll add a reference to variables_order
there.

This bug remains open and I believe remains until a solution is found
that doesn't affect BC.  Obviously some concern exists, see that
thread.  There was a time when the register_globals directive didn't
even exist.


Previous Comments:
------------------------------------------------------------------------

[2002-07-10 13:46:01] rlm@pricegrabber.com

In WHICH "various places" is this misbehavior documented?  And why is
it NOT documented in the one place it should be mandatory -- the
"track_vars" documentation?

http://www.php.net/manual/en/configuration.php#ini.track-vars

And finally -- since you brought it up -- why isn't track_vars
functional obsolescence documented along with that variable?

I've said it before, and in this same bug -- this behavior amounts to
poor design under the "least surprise" principle.

------------------------------------------------------------------------

[2002-07-10 13:13:10] philip@php.net

This behavior is documented in various places and is expected.  When
the variables_order documentation says "PHP will completely ignore
them" it really means it.  There was talk of adding additional
directives but nothing came of it (yet?).  See:

 http://marc.theaimsgroup.com/?l=php-dev&m=101194050211581
 http://marc.theaimsgroup.com/?l=php-dev&m=101194642021528
  
On a related note, track_vars doesn't do anything as of PHP 4.0.3.
Also, even if variables_order lacks an E you can still use getenv() and
the E info is still shown in phpinfo().  So I guess PHP never
completely ignores E :)   

------------------------------------------------------------------------

[2002-07-10 10:00:06] ftm@gtd.es

I've experienced the same problem with Win2000Pro + Apache 1.3.26 + PHP
4.2.1

Hope this can be useful... and please fix it soon ;)

Fermí.

------------------------------------------------------------------------

[2002-03-19 18:56:10] rlm@pricegrabber.com

I have confirmed this using just the /etc/php.ini file.  Unless
variables_order is set for the corresponding variable, the superglobal
doesn't get set.

------------------------------------------------------------------------

[2002-03-19 11:42:23] rlm@pricegrabber.com

To clarify:

1) There is no reason why variables_order should have any effect
whatsoever on whether _GET, _POST, _COOKIE, or HTTP_*_VARS are set. 
Ever.  Read the documentation on track_vars for why, but it certainly
says they can be found WITHOUT mentioning any side effects of
variables_order.  At the very least, this is a documentation bug.  At
worst (and in reality) this is a violation of the "principle of least
surprise"; that is, when does "can be found" not mean "can be found"? 
What possible use could a programmer have for disabling EGPCS variable
parsing to the extent of disabling _GET, _POST, etc.?

2) Even allowing for all the above, this should all work if the
directives are in Apache.  It doesn't.

------------------------------------------------------------------------

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/16155

-- 
Edit this bug report at http://bugs.php.net/?id=16155&edit=1



Thread (21 messages)

« previous php.bugs (#13758) next »