Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35274
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <47AA5354.7020806@zend.com>
Date: Wed, 06 Feb 2008 16:39:48 -0800
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: 'PHP Internals' <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: _REQUEST and variable_order
From: stas@zend.com (Stanislav Malyshev)

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?
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com