Re: _REQUEST and variable_order
| From: | Sam Barrow | Date: | Thu, 07 Feb 2008 04:45:09 +0000 |
| Subject: | Re: _REQUEST and variable_order | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-35280@lists.php.net to get a copy of this message | ||
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.
True. Why not an ini setting, request_variables that works the same as
variables_order, just for $_REQUEST.
> -Rasmus
>