Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: jani.taskinen@iki.fi, 'PHP Internals' <internals@lists.php.net>
In-Reply-To: <47AADAB2.8090100@lerdorf.com>
References: <47AA5354.7020806@zend.com>  <47AA88A9.4000802@lerdorf.com>
	 <1202376366.26463.3.camel@localhost.localdomain>
	 <47AAD2BD.1030804@lerdorf.com>
	 <1202378529.26463.19.camel@localhost.localdomain>
	 <47AADAB2.8090100@lerdorf.com>
Content-Type: text/plain
Date: Thu, 07 Feb 2008 08:03:39 -0500
Message-ID: <1202389419.6436.1.camel@sbarrow-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] _REQUEST and variable_order
From: sam@sambarrow.com (Sam Barrow)

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
>