Edit report at http://bugs.php.net/bug.php?id=16155&edit=1
ID: 16155 Updated by: [email protected] Reported by: rlm at pricegrabber dot com Summary: variables_order affects existence of php predefined variables -Status: Open +Status: Bogus Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: all PHP Version: 4CVS Block user comment: N Private report: N New Comment: Quite irrelevant request since there is no track_vars anymore. And lot of other means to access this stuff. Previous Comments: ------------------------------------------------------------------------ [2002-10-07 12:38:20] [email protected] feature request-> php options bug ------------------------------------------------------------------------ [2002-07-10 20:08:46] [email protected] This is a feature request as it's documented and expected bahavior. Your points are valid and shared by many. It's a matter of sitting down, thinking it through, and coming up with a nice BC friendly solution. In speaking with Zeev, he tentively suggested the following: (a) Decouple variables_order from the $_* / $HTTP_*_VARS completely. (b) Make it possible to prevent $_ENV and $_SERVER from being populated. Like env_autoglobal = on and server_autoglobal = on. (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. This falls in line with your suggestions. The current variables_order manual entry is vague on this particular matter, yes, but it's there, and it's much clearer in the other aforementioned entries. With variables_order = GPCS and register_globals = off, the global namespace will not be polluted. Not sure what you mean there as $_GET['id'] will exist, $id will not. ------------------------------------------------------------------------ [2002-07-10 18:57:33] rlm at pricegrabber dot com No, it won't, because that will also add the variables to the global namespace. This is not a feature request -- it's *making the system work as advertised*. There already is -- or should be, if the writers of the documentation were correct -- a way to disable global variable imports, which ought to be the configuration lines register_globals = Off variables_order = "" That is, - register_globals should control the registration of globals, and - variables_order should control the source(s) of and order of global variable parsing. Just like it says in the documentation: "variables_order string Set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". Setting this to "GP", for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to overwrite any GET method variables with POST-method variables of the same name." Notice how the above makes NO mention of whether track_vars is set -- but that doesn't matter, because track_vars IS ALWAYS SET ON! That implies that variable tracking in HTTP_*_VARS should ALWAYS happen. ALWAYS. The tools to do this already exists. This is not a feature but a bug -- the extant documentation describes a rationally behaving environment, but PHP no longer conforms to it. ------------------------------------------------------------------------ [2002-07-10 18:21:53] [email protected] Just set the PHP predefined variables you want in the variables_order directive. Like, GPCS or EGPCS. And turn register_globals off. This will do what you want. I'm turning this into a feature request and changing the summary. See Rasmus' post/thread for details on this request. Whoever decided that variables_order should be 'es' during your install should be informed on the matter too. ------------------------------------------------------------------------ [2002-07-10 16:37:44] rlm at pricegrabber dot com See my earlier comments but the possibility of the combination of track_vars=on and register_globals=off is entirely desirable. That is, we want PHP to pick up variables from the URL, POST, cookies, etc. into HTTP_GET_VARS etc. WITHOUT importing them into the namespace. ------------------------------------------------------------------------ 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/bug.php?id=16155 -- Edit this bug report at http://bugs.php.net/bug.php?id=16155&edit=1
