Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.178 cause and error)
Reply-To: jani.taskinen@iki.fi
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: jani.taskinen@iki.fi, 'PHP Internals' <internals@lists.php.net>
In-Reply-To: <47AAD2BD.1030804@lerdorf.com>
References: <47AA5354.7020806@zend.com>  <47AA88A9.4000802@lerdorf.com>
	 <1202376366.26463.3.camel@localhost.localdomain>
	 <47AAD2BD.1030804@lerdorf.com>
Content-Type: text/plain
Date: Thu, 07 Feb 2008 12:02:08 +0200
Message-ID: <1202378529.26463.19.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] _REQUEST and variable_order
From: jani.taskinen@sci.fi (Jani Taskinen)

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?

> > 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? :)

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?

--Jani
 
-- 
Patches/Donations: http://pecl.php.net/~jani/