On Thu, 2008-02-07 at 02:17 -0800, Rasmus Lerdorf wrote: > 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"
I agree with this. Either a compatibility setting like request_include_cookie or an ini setting allowing you to completely control the content in request (as well as order of precedence). For example, request_order = GPC, GP, PG, ... > -Rasmus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
