A minor clarification: The auto-globals are always there, they're not always _populated_ though. (JIC someone misunderstood this part :)
On Thu, 2008-02-07 at 02:17 -0800, Rasmus Lerdorf wrote: [clip] > directives. We should focus on the actual problem and make the fewest > changes possible to solve that. The actual problem being that by > default cookie data is in $_REQUEST and that can lead to problems. So, > we change that default. Now, in the few cases out there where someone So instead of EGPCS the default value of variables_order will be EGPS? > really does want cookie data in $_REQUEST we can provide an ini for them > to enable that. Since today we don't have the ability to have cookie > data in $_REQUEST without also having $_COOKIE present, we won't break > anything by not supporting that edge case. So I think we can tie the > two together and perhaps throw a startup error if someone tries to make > $_REQUEST contain cookie data if variables_order does not include "C" Sounds reasonable. OTOH, what's keeping us from populating the $_REQUEST global "on-demand"? So even if C is not in variables_order but is set in request_variables_order the entries for '$_COOKIE' would be in $_REQUEST but $_COOKIE itself would be empty still. By quick glance to the code would suggest that it should be fairly easy to check in php_auto_globals_create_request() if e.g. Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_COOKIE] is populated or not and if not, call sapi_module.treat_data() there. --Jani -- Patches/Donations: http://pecl.php.net/~jani/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
