ID: 16155
Updated by: rlm@pricegrabber.com
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2002-03-19 10:19:40] rlm@pricegrabber.com
No, it is a bug. The problem is that if the configuration data comes
from Apache rather than /etc/php.ini, the tracking variables aren't
initialized correctly as described.
------------------------------------------------------------------------
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