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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
