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