Jani Taskinen wrote: > On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: >> Jani Taskinen wrote: >>> On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: >>>> Stanislav Malyshev wrote: >>>>> The proposal(s): >>>>> 1. One way to fix it is to create a new .ini request_order that would >>>>> control just _REQUEST. >>>>> >>>>> 2. Other solution would be to keep variables_order but drop 'C' parsing >>>>> from _REQUEST - i.e. make _REQUEST never include cookies. I don't know >>>>> how many people really need cookies together with get/post in REQUEST. >>>>> >>>>> 3. Yet another solution would be to make superglobals independent of >>>>> variables_order - i.e. _COOKIE would always exist even if >>>>> variables_order doesn't have the letter. I actually don't see any reason >>>>> having JIT to remove any of the superglobals - if you don't use them, >>>>> with JIT you don't pay for them. And with COOKIES it's not that it would >>>>> be a big cost anyway - how many cookies could you have? >>>>> Of course, it'd be more substantial change which could break some apps >>>>> relying on some quirks of current behavior. >>>>> >>>>> So, what do you think on this? >>>> They are all about equivalent. Even #3 would need some sort of ini >>>> override since otherwise it removes some flexibility we have today. >>>> There are setups that specifically rely on disabling $_COOKIE to force >>>> code to go through other mechanisms to get at the cookies. > > I missed this from your mail. Sounds a very weird idea, do they set > $_COOKIE themselves then? And can I ask where such setup is used?
Very large sites with signed and encrypted cookies containing lots of sub-parts will typically want to only decrypt and validate these cookies once. Likely before they even get to PHP and provide an API to get at them instead of having all the bits downstream each try to parse the raw $_COOKIE value. Being able to turn off $_COOKIE altogether helps make sure everyone follows that approach. >>> I pick door #3. >> Well, plenty of people know about this feature and make use of it. >> Especially since it has been documented to work this way for a long time. >> See: http://php.net/manual/en/ini.core.php#ini.variables-order > > But was it really designed to work like that? :) It was actually. Initially it was designed that way for performance reasons. Populating $_ENV on every single request if you weren't going to use it made no sense. This was obviously pre-JIT. In a pre-JIT world being able to disable these made a lot of sense. Now the performance reason is mostly gone, but it still leaves us with applications that don't expect them to be there. Worst-case we have configurations that explicitly have turned them off and create their own $_COOKIE array to implement a local security policy. Having the superglobal show up and populate what they thought was a locally created array could cause security problems. > Anyway, I guess there's no other way out of this than creating another > ini option, say "request_variables_order" which controls whatever goes > in $_REQUEST. But would the "variables_order" still control the overal > situation? For example when it is set to "GP" and > "request_variables_order" is set to "GPC", would $_REQUEST have all of > $_GET / $_POST / $_COOKIE regardless what "variables_order" has in it? The less we change, the better. That includes the meanings of existing 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 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" -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
