Bug #13645 Updated: variables_order influences HTTP_*_VARS

ID: 13645 Updated by: mfischer@php.net Reported By: hp@oeri.ch -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: Mandrake Linux 8.0 PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2001-10-20 20:16:07] sniper@php.net This is intended behaviour but you're right about it not being documented. This should be mentioned at: http://www.php.net/manual/en/language.variables.predefined.php Also, the new global variables for 4.1.0 are undocumented: $_GET $_POST $_COOKIE $_SERVER $_ENV $_FILES $_REQUEST and import_request_variables() function is not documented. --Jani p.s. track_vars is enabled always regardless of any settings since 4.0.3 ------------------------------------------------------------------------ [2001-10-11 18:10:00] hp@oeri.ch As for the logic of the php.ini texts, I understand variables_order defines the order in which vars are assigned into global space. track_vars should enable ALL HTTP_*_VARS. However, leaving out one of egpcs in variables_order disables the corresponding HTTP_*_VARS! (empty array) Besides the point, that this seems to be not-as-documented, "correct" behaviour would solve a whole lot of security problems: ; only assign "safe" variables to global space, but DO ; assign them -> convenience for safe vars! variables_order = "S" ; access all other by HTTP_*_VARS track_vars = on Please correct me, if I'm wrong. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=13645&edit=1