Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35283
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <47AAD2BD.1030804@lerdorf.com>
Date: Thu, 07 Feb 2008 01:43:25 -0800
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: jani.taskinen@iki.fi
CC: "'PHP Internals'" <internals@lists.php.net>
References: <47AA5354.7020806@zend.com>  <47AA88A9.4000802@lerdorf.com> <1202376366.26463.3.camel@localhost.localdomain>
In-Reply-To: <1202376366.26463.3.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] _REQUEST and variable_order
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Jani Taskinen wrote:
> On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote:
>> Stanislav Malyshev wrote:
>>> Hi!
>>>
>>> This topic was already discussed here but never arrived to a conclusion, 
>>> so I will raise it again.
>>> The Problem:
>>> We have $_REQUEST superglobal, which is often used to abstract GET/POST 
>>> requests. However, in most cases we do not want GET/POST variables to 
>>> mean the same as cookie and environment variables. We can avoid that by 
>>> setting variables_order to 'GP' but then we lose _SERVER and _COOKIES 
>>> which still can be very much useful. We cannot also reliably use 
>>> something like 'CGP' since while it won't allow cookies to override 
>>> GET/POST we still have no way of not accepting cookie that has no 
>>> matching GET/POST. I think this should be cleaned up so that _REQUEST 
>>> behavior would conform its use case.
>>>
>>> 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.
>>
>> Perhaps a combination of 1 and 2.  By default drop cookies from
>> $_REQUEST but have an ini override for the few cases where the app
>> actually relies on this behaviour.  I have seen multi-page forms where
>> instead of bouncing previous inputs along in hidden fields it gets
>> transmitted in cookies and they use $_REQUEST to keep track of all of
>> the responses.
> 
> What's wrong with the option 3? $_GET / $_POST / $_COOKIE should
> _always_ be there regardless of any ini setting.  I didn't even know
> (before Stas brought it up) that variables_order affects these so in my
> book that's just a bug that needs fixing. And does not require any new
> ini options.. :)
> 
> 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

"Sets the order of the EGPCS (Environment, Get, Post, Cookie, and
 Server) variable parsing. For example, if variables_order is set to
 "SP" then PHP will create the superglobals $_SERVER and $_POST, but not
 create $_ENV, $_GET, and $_COOKIE. Setting to "" means no superglobals
 will be set."

-Rasmus