# _REQUEST and variable_order

- Thread: https://externals.io/message/35274
- Original archive: https://news-web.php.net/php.internals/35274
- Started by Stanislav Malyshev on 2008-02-07T00:39:48+00:00
- Messages: 21
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #35274 — Stanislav Malyshev — 2008-02-07T00:39:48+00:00

URL: https://externals.io/message/35274#35274

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

---

## #35275 — Sam Barrow — 2008-02-07T00:50:05+00:00

URL: https://externals.io/message/35274#35275 · In reply to: #35274

> 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.

I like this. $_REQUEST is used by me and most PHP developers I know
solely for the purpose of abstracting $_GET and $_POST. But user input
never comes directly from cookies (what user fills in a login form by
setting cookies?), so I don't see a point of including them.

> 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

---

## #35277 — Jessie Hernandez — 2008-02-07T03:36:45+00:00

URL: https://externals.io/message/35274#35277 · In reply to: #35275

Sam Barrow wrote:
> 
[snip]
> > […]
> 
> I like this. $_REQUEST is used by me and most PHP developers I know
> solely for the purpose of abstracting $_GET and $_POST. But user input
> never comes directly from cookies (what user fills in a login form by
> setting cookies?), so I don't see a point of including them.
> 

I also like solution #2, I always read cookies using $_COOKIE.


-- 

Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)

---

## #35279 — Rasmus Lerdorf — 2008-02-07T04:27:21+00:00

URL: https://externals.io/message/35274#35279 · In reply to: #35274

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.

-Rasmus

---

## #35280 — Sam Barrow — 2008-02-07T04:45:09+00:00

URL: https://externals.io/message/35274#35280 · In reply to: #35279

> Stanislav Malyshev wrote:
> > […]
> 
> 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

---

## #35282 — Jani Taskinen — 2008-02-07T09:26:06+00:00

URL: https://externals.io/message/35274#35282 · In reply to: #35279

> Stanislav Malyshev wrote:
> > […]
> 
> 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/

---

## #35283 — Rasmus Lerdorf — 2008-02-07T09:43:25+00:00

URL: https://externals.io/message/35274#35283 · In reply to: #35282

Jani Taskinen wrote:
> 
> > […]
> 
> 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

---

## #35284 — Jani Taskinen — 2008-02-07T10:02:08+00:00

URL: https://externals.io/message/35274#35284 · In reply to: #35283

> Jani Taskinen wrote:
> > […]

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?

> > […]
> 
> 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/

---

## #35286 — Rasmus Lerdorf — 2008-02-07T10:17:22+00:00

URL: https://externals.io/message/35274#35286 · In reply to: #35284

Jani Taskinen wrote:
> 
> > […]
> 
> 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?

Very large sites with signed and encrypted cookies containing lots of
sub-parts will typically want to only decrypt and validate these cookies
once.  Likely before they even get to PHP and provide an API to get at
them instead of having all the bits downstream each try to parse the raw
$_COOKIE value.  Being able to turn off $_COOKIE altogether helps make
sure everyone follows that approach.

> > […]
> 
> But was it really designed to work like that? :)

It was actually.  Initially it was designed that way for performance
reasons.  Populating $_ENV on every single request if you weren't going
to use it made no sense.  This was obviously pre-JIT.  In a pre-JIT
world being able to disable these made a lot of sense.  Now the
performance reason is mostly gone, but it still leaves us with
applications that don't expect them to be there.  Worst-case we have
configurations that explicitly have turned them off and create their own
$_COOKIE array to implement a local security policy.  Having the
superglobal show up and populate what they thought was a locally created
array could cause security problems.

> 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?

The less we change, the better.  That includes the meanings of existing
directives.  We should focus on the actual problem and make the fewest
changes possible to solve that.  The actual problem being that by
default cookie data is in $_REQUEST and that can lead to problems.  So,
we change that default.  Now, in the few cases out there where someone
really does want cookie data in $_REQUEST we can provide an ini for them
to enable that.  Since today we don't have the ability to have cookie
data in $_REQUEST without also having $_COOKIE present, we won't break
anything by not supporting that edge case.  So I think we can tie the
two together and perhaps throw a startup error if someone tries to make
$_REQUEST contain cookie data if variables_order does not include "C"

-Rasmus

---

## #35290 — Jani Taskinen — 2008-02-07T11:15:20+00:00

URL: https://externals.io/message/35274#35290 · In reply to: #35286

A minor clarification: The auto-globals are always there, they're not
always _populated_ though. (JIC someone misunderstood this part :)


[clip]
> directives.  We should focus on the actual problem and make the fewest
> changes possible to solve that.  The actual problem being that by
> default cookie data is in $_REQUEST and that can lead to problems.  So,
> we change that default.  Now, in the few cases out there where someone

So instead of EGPCS the default value of variables_order will be EGPS? 

> really does want cookie data in $_REQUEST we can provide an ini for them
> to enable that.  Since today we don't have the ability to have cookie
> data in $_REQUEST without also having $_COOKIE present, we won't break
> anything by not supporting that edge case.  So I think we can tie the
> two together and perhaps throw a startup error if someone tries to make
> $_REQUEST contain cookie data if variables_order does not include "C"

Sounds reasonable. OTOH, what's keeping us from populating the $_REQUEST
global "on-demand"? So even if C is not in variables_order but is set in
request_variables_order the entries for '$_COOKIE' would be in $_REQUEST
but $_COOKIE itself would be empty still. By quick glance to the code
would suggest that it should be fairly easy to check in
php_auto_globals_create_request() if e.g.
Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_COOKIE] is populated or not and
if not, call sapi_module.treat_data() there.

--Jani

-- 
Patches/Donations: http://pecl.php.net/~jani/

---

## #35293 — dz@bitxtender.com — 2008-02-07T11:50:36+00:00

URL: https://externals.io/message/35274#35293 · In reply to: #35284

Am 07.02.2008 um 11:02 schrieb Jani Taskinen:

> 
> > […]
>
> 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?

Mh, "request_variables_order" is probably not the best idea given it  
can be pretty confusing when compared to "variables_order" - and nore  
so if you look at what "variables_order" really does; the only "order"  
it defines is that of the $_REQUEST merging, but I doubt many people  
know that removing something from that var also suppressed the  
respective superglobal entirely.
Maybe "request_populate_order" or so?


- David

---

## #35296 — Sam Barrow — 2008-02-07T13:03:39+00:00

URL: https://externals.io/message/35274#35296 · In reply to: #35286

> Jani Taskinen wrote:
> > […]
> 
> Very large sites with signed and encrypted cookies containing lots of
> sub-parts will typically want to only decrypt and validate these cookies
> once.  Likely before they even get to PHP and provide an API to get at
> them instead of having all the bits downstream each try to parse the raw
> $_COOKIE value.  Being able to turn off $_COOKIE altogether helps make
> sure everyone follows that approach.
> 
> > […]
> 
> It was actually.  Initially it was designed that way for performance
> reasons.  Populating $_ENV on every single request if you weren't going
> to use it made no sense.  This was obviously pre-JIT.  In a pre-JIT
> world being able to disable these made a lot of sense.  Now the
> performance reason is mostly gone, but it still leaves us with
> applications that don't expect them to be there.  Worst-case we have
> configurations that explicitly have turned them off and create their own
> $_COOKIE array to implement a local security policy.  Having the
> superglobal show up and populate what they thought was a locally created
> array could cause security problems.
> 
> > […]
> 
> The less we change, the better.  That includes the meanings of existing
> directives.  We should focus on the actual problem and make the fewest
> changes possible to solve that.  The actual problem being that by
> default cookie data is in $_REQUEST and that can lead to problems.  So,
> we change that default.  Now, in the few cases out there where someone
> really does want cookie data in $_REQUEST we can provide an ini for them
> to enable that.  Since today we don't have the ability to have cookie
> data in $_REQUEST without also having $_COOKIE present, we won't break
> anything by not supporting that edge case.  So I think we can tie the
> two together and perhaps throw a startup error if someone tries to make
> $_REQUEST contain cookie data if variables_order does not include "C"

I agree with this. Either a compatibility setting like
request_include_cookie or an ini setting allowing you to completely
control the content in request (as well as order of precedence). For
example, request_order = GPC, GP, PG, ...

> -Rasmus

---

## #35354 — Derick Rethans — 2008-02-11T08:45:00+00:00

URL: https://externals.io/message/35274#35354 · In reply to: #35274

> So, what do you think on this?

Don't care so much about it, as long as the defaults keep the same like 
they are now.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #35456 — Stanislav Malyshev — 2008-02-13T21:02:05+00:00

URL: https://externals.io/message/35274#35456 · In reply to: #35274

> matching GET/POST. I think this should be cleaned up so that _REQUEST 
> behavior would conform its use case.

Attached is the patch that implements request_order .ini value. Comments?

-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #35457 — Derick Rethans — 2008-02-13T21:11:44+00:00

URL: https://externals.io/message/35274#35457 · In reply to: #35456

> > […]
> 
> Attached is the patch that implements request_order .ini value. Comments?

Yes...  I didn't seem to see a default:

+       STD_PHP_INI_ENTRY("request_order",                      NULL,           PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order,          php_core_globals,       core_globals)

Which means that without this setting, nothing ends up in request. The 
default should be what it is now ("GPC"). The same is true for 
php.ini-dist - it should mention the default (still commented out, just 
like the rest) as "GPC" too.

regards,
-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #35458 — Stanislav Malyshev — 2008-02-13T21:19:19+00:00

URL: https://externals.io/message/35274#35458 · In reply to: #35457

> Yes...  I didn't seem to see a default:
> 
> +       STD_PHP_INI_ENTRY("request_order",                      NULL,           PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order,          php_core_globals,       core_globals)
> 
> Which means that without this setting, nothing ends up in request. The 

 `NULL` means variable_order is used.

> php.ini-dist - it should mention the default (still commented out, just 
> like the rest) as "GPC" too.

Setting this as GPC gives wrong idea - recommended setting is GP, as C 
is useful only in very rare situations for special applications.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #35459 — Derick Rethans — 2008-02-13T21:40:59+00:00

URL: https://externals.io/message/35274#35459 · In reply to: #35458

> > […]
> 
> `NULL` means variable_order is used.
> 
> > […]
> 
> Setting this as GPC gives wrong idea - recommended setting is GP, as C is
> useful only in very rare situations for special applications.

Yes, that's why php.ini-recommended should have GP. However, 
php.ini-dist documents *the default* - which should be GPC, like it is 
right now. 

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #35460 — Stanislav Malyshev — 2008-02-13T21:50:14+00:00

URL: https://externals.io/message/35274#35460 · In reply to: #35459

> Yes, that's why php.ini-recommended should have GP. However, 
> php.ini-dist documents *the default* - which should be GPC, like it is 
> right now. 

The default is NULL, which means using variables_order - just as before. 
  I don't see a lot of reason to change it to GPC - it would be neither 
old compatible way (using variables_order) nor new recommended way 
(using request_order=GP).
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #35536 — Philip Olson — 2008-02-16T00:21:26+00:00

URL: https://externals.io/message/35274#35536 · In reply to: #35460

> > […]
>
> The default is NULL, which means using variables_order - just as  
> before.  I don't see a lot of reason to change it to GPC - it would  
> be neither old compatible way (using variables_order) nor new  
> recommended way (using request_order=GP).

The default behaviour is proper in php.ini-dist and GPC is the  
default if no php.ini exists. The use of GP should be documented in  
php.ini-recommended like the other changes there, but php.ini-dist is  
not the place for that except it should mention that variables_order  
is the default like it currently does in the patch.

Regards,
Philip

---

## #35563 — Richard Lynch — 2008-02-18T21:32:31+00:00

URL: https://externals.io/message/35274#35563 · In reply to: #35274

> 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?

I would like to see $_REQUEST be just GET | POST

I also see no reason to not keep $_GET if 'G' is missing from GPC
ordering, so that would be a fine second choice.

Introducing yet another php.ini setting to fix this for the number of
people it affects seems a bit like the old cannon for a fly solution
to this naive reader.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

---

## #35601 — Stanislav Malyshev — 2008-02-19T17:49:09+00:00

URL: https://externals.io/message/35274#35601 · In reply to: #35563

> I would like to see $_REQUEST be just GET | POST

That's what ini-recommended is configured for.

> I also see no reason to not keep $_GET if 'G' is missing from GPC
> ordering, so that would be a fine second choice.

That changes semantics of existing switch, so I don't feel comfortable 
to do such change...
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com