# Why does $_REQUEST exist?

- Thread: https://externals.io/message/43935
- Original archive: https://news-web.php.net/php.internals/43935
- Started by Michael Shadle on 2009-05-14T17:18:38+00:00
- Messages: 17
- 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

---

## #43935 — Michael Shadle — 2009-05-14T17:18:38+00:00

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

To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.

I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)

If people want something like $_REQUEST they can make their own

$_REQUEST = array_merge($_GET, $_POST, etc)

or

if(isset($_GET['myvar'])) {
  do stuff;
} elseif(isset($_POST['myvar'])) {
  do stuff;
}

I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.

Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)

I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...

I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?

Thanks,
mike

---

## #43963 — Nathan Rixham — 2009-05-14T22:03:02+00:00

URL: https://externals.io/message/43935#43963 · In reply to: #43935

Michael Shadle wrote:
> To me, it basically creates some laziness and reintroduces a vector on
> the register_globals issue.
> 
> I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
> they were introduced, and have never had any problems. Was there a
> reasoning behind making a variable that essentially glues them all
> (well, most) together again and allows for a POST to override a GET or
> a SESSION var (depending on your settings of course)
> 
> If people want something like $_REQUEST they can make their own
> 
> $_REQUEST = array_merge($_GET, $_POST, etc)
> 
> or
> 
> if(isset($_GET['myvar'])) {
>   do stuff;
> } elseif(isset($_POST['myvar'])) {
>   do stuff;
> }
> 
> I actually unset($_REQUEST) in my framework so the developers on my
> team can't use it. If I ever have a mixed source where I'm not sure if
> it it's a POST or GET, I use an example like the second one - that
> gives me ultimate control of the order in which I trust the variables
> and such.
> 
> Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
> code change requirements, I would personally recommend removing
> $_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
> other long versions, again, something I unset just in case some junior
> developer steals some code or doesn't understand the shorthand
> superglobal exists already...)
> 
> I can see (albeit with mixed acceptance) the need to look at GET,
> POST, and whatever other sources $_REQUEST might pull in for some
> certain applications because they're not sure if it comes through.
> Personally I always make sure it comes through one way or the other;
> but I guess that is not always the case. But for those cases, there
> are easy enough ways to code around it, doing something like example
> #1, for instance. Then, you can control the order of trust wherever
> you use it - perhaps sometimes you want to prefer POST first,
> sometimes you want to prefer SESSION first, etc...
> 
> I don't know of any other reasoning behind this and have brought this
> up with many people, possibly even this list in the past. But since
> changes have to occur anyway for 5.3 and 6, maybe one of those can
> actually implement this removal?
> 
> Thanks,
> mike

bc? all the reasoning in the world won't justify it to 1 million 
businesses running php 4 code which is reliant on $_REQUEST behind the 
scenes.

although it would generate a tonne of freelance work :p

---

## #43966 — Michael Shadle — 2009-05-15T00:33:21+00:00

URL: https://externals.io/message/43935#43966 · In reply to: #43963

> bc? all the reasoning in the world won't justify it to 1 million businesses
> running php 4 code which is reliant on $_REQUEST behind the scenes.
>
> although it would generate a tonne of freelance work :p

that code has to change for 5.3 or 6.0 anyway.

now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?

---

## #43969 — Patrick ALLAERT — 2009-05-15T06:01:00+00:00

URL: https://externals.io/message/43935#43969 · In reply to: #43966

2009/5/15 Michael Shadle <mike503@gmail.com>
>
> 
>
> > […]
>
> that code has to change for 5.3 or 6.0 anyway.
>
> now is the time to yank out some of the legacy crap. we don't want PHP
> to be like windows, do we?

Hello,

I think Michael's vision is right in this area, maybe bc could just be
achieved having a "register_request" INI parameter that is set by
default to OFF that people just have to enable if they rely on
$_REQUEST.
We could manage it the same way register_globals is:
"This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0"

Patrick

---

## #43970 — Michael Shadle — 2009-05-15T06:09:52+00:00

URL: https://externals.io/message/43935#43970 · In reply to: #43969

I think this strikes a good balance between backward compatibility...

I would hope though the code for it is very simple, to not add
overhead to PHP. Basically in PHP the pseudocode equivalent would be

if(ini_get('reigster_request') == true) {
  $_REQUEST = array_merge($_GET, $_POST, $_COOKIE, $_SESSION);
}

On Thu, May 14, 2009 at 11:01 PM, Patrick ALLAERT
<patrick.allaert@gmail.com> wrote:

> Hello,
>
> I think Michael's vision is right in this area, maybe bc could just be
> achieved having a "register_request" INI parameter that is set by
> default to OFF that people just have to enable if they rely on
> $_REQUEST.
> We could manage it the same way register_globals is:
> "This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0"
>
> Patrick

---

## #43973 — Rasmus Lerdorf — 2009-05-15T08:22:32+00:00

URL: https://externals.io/message/43935#43973 · In reply to: #43966

Michael Shadle wrote:
> 
> 
> > […]
> 
> that code has to change for 5.3 or 6.0 anyway.
> 
> now is the time to yank out some of the legacy crap. we don't want PHP
> to be like windows, do we?

The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP.  That
causes way more frustration for everyone than a few "ugly" legacy
features.  If there is a decent technical reason, performance or
security, then we need to take a hard look at it.  In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it.  Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST.  Most people use
$_REQUEST to mean GET or POST, not realizing that it could also contain
cookies and as such bad guys could potentially do some cookie injection
tricks and break naive applications.

-Rasmus

---

## #43975 — Lukas Kahwe Smith — 2009-05-15T08:32:07+00:00

URL: https://externals.io/message/43935#43975 · In reply to: #43973

> Michael Shadle wrote:
> > […]
>
> The more stuff like this we remove, the harder it becomes for people  
> to
> quickly move to newer, faster and more secure versions of PHP.  That
> causes way more frustration for everyone than a few "ugly" legacy
> features.  If there is a decent technical reason, performance or
> security, then we need to take a hard look at it.  In this case, the
> thing we should be looking at isn't whether we should remove $_REQUEST
> but whether we should remove cookie data from it.  Many configurations
> already do that, including all of my own, and there is a strong valid
> security reason for not including cookies in $_REQUEST.  Most people  
> use
> $_REQUEST to mean GET or POST, not realizing that it could also  
> contain
> cookies and as such bad guys could potentially do some cookie  
> injection
> tricks and break naive applications.


Its already fixed in 5.3. There is a new ini option that defines what  
should go into $_REQUEST. See the following blog post for details:
http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/

Also a lot of work was put into restructuring the php.ini files we  
ship with PHP.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #43977 — Rasmus Lerdorf — 2009-05-15T08:37:41+00:00

URL: https://externals.io/message/43935#43977 · In reply to: #43975

Lukas Kahwe Smith wrote:
> 
> 
> 
> > […]
> 
> 
> Its already fixed in 5.3. There is a new ini option that defines what
> should go into $_REQUEST. See the following blog post for details:
> http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/
> 
> 
> Also a lot of work was put into restructuring the php.ini files we ship
> with PHP.

Right, I obviously know that, I should have explained better.  What I
meant by removing cookie data from $_REQUEST was to never allow it at
all.  Right now you have to set request_order to "GP" in order to not
get it.  If, like most people, you upgrade and use the same php.ini file
as before, then we default back to variables_order which has always
included cookie data by default.  So, as much as I appreciate the work
that has gone into the new recommended php.ini settings, we all know
that most people completely ignore our .ini suggestions and go with
whatever their distro chooses or whatever they have had in there since
their PHP4 days.  My prediction is that the bulk of people after
upgrading to 5.3 will still have cookies in their $_REQUEST.

-Rasmus

---

## #43979 — Hannes Magnusson — 2009-05-15T08:40:49+00:00

URL: https://externals.io/message/43935#43979 · In reply to: #43975

>
> 
>
> > […]
>
>
> Its already fixed in 5.3. There is a new ini option that defines what should
> go into $_REQUEST. See the following blog post for details:

And simplified version in the docs http://php.net/request_order

-Hannes

---

## #43993 — Michael Shadle — 2009-05-15T17:14:38+00:00

URL: https://externals.io/message/43935#43993 · In reply to: #43975

> > […]

But since there is going to be a dramatic change here anyway, this is
the perfect time to do it. To me adding namespaces is a lot more scary
and will lead to a lot of confusing code...

P.S. It looks like you'll be speaking at OSBridge in Portland in a
month or so. If I attend I look forward to meeting you and thanking
you for PHP :)

> Its already fixed in 5.3. There is a new ini option that defines what should
> go into $_REQUEST. See the following blog post for details:
> http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/
>
> Also a lot of work was put into restructuring the php.ini files we ship with
> PHP.

This is a good step I think; will it be possible to allow it to be
empty and have $_REQUEST not exist or even be initialized?

Also, you said it yourself in your blog - not caring what is done via
GET and POST is bad practice. Why not enforce this in the engine?

It makes PHP look insecure when apps have security issues because of
poor coding. It's not because PHP itself had a flaw, but to a lot of
people, they see "PHPNuke" or know that postnuke runs under PHP, or
phpbb, etc - the language -can- enforce better techniques, especially
since 5.3 and 6.0 will require some changes in code anyway; this one
is a pretty simple change too -

Someone could make a function like import_request_variables() but
allow it to re-create $_REQUEST and tell people to put it at the top
of their scripts or a central include file if they're too lazy to fix
their code to be more secure. I for one would love to see this be
enforced at the engine level, so that packages I wind up having to use
like Wordpress/etc. have been forced to change their logic (hopefully)
to go back to $_GET, $_POST etc.

Also, I had thought $_REQUEST had included session data too. At least
that is not there. Talk about easy exploitation options then! :)

---

## #43997 — Lukas Kahwe Smith — 2009-05-15T20:25:53+00:00

URL: https://externals.io/message/43935#43997 · In reply to: #43993

> On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith  
> <mls@pooteeweet.org> wrote:
>
> > […]
>
> But since there is going to be a dramatic change here anyway, this is
> the perfect time to do it. To me adding namespaces is a lot more scary
> and will lead to a lot of confusing code...

Confusing new code is totally different from breaking existing code.

> > […]
>
> This is a good step I think; will it be possible to allow it to be
> empty and have $_REQUEST not exist or even be initialized?
>
> Also, you said it yourself in your blog - not caring what is done via
> GET and POST is bad practice. Why not enforce this in the engine?

Just FYI: Not sure which blog you are talking about, but that is  
Stefan Esser's blog that is linked above.

> Also, I had thought $_REQUEST had included session data too. At least
> that is not there. Talk about easy exploitation options then! :)


Indeed, that would have been insane.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #43999 — Michael Shadle — 2009-05-15T21:32:45+00:00

URL: https://externals.io/message/43935#43999 · In reply to: #43997

> Confusing new code is totally different from breaking existing code.

True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be "legacy enough" ?

There's gotta be a time in the natural evolution to "cut the cord" so
to speak - Python just launched 3.0 and dropped backwards
compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I
care. But it really should align with a major revision #)

> Just FYI: Not sure which blog you are talking about, but that is Stefan
> Esser's blog that is linked above.

Sorry, used to most people pushing their own blog links :)

---

## #44000 — Sven Drieling — 2009-05-15T22:14:30+00:00

URL: https://externals.io/message/43935#44000 · In reply to: #43999

Am Freitag, 15. Mai 2009 schrieb Michael Shadle:

Hallo,

> There's gotta be a time in the natural evolution to "cut the cord" so
> to speak - Python just launched 3.0 and dropped backwards
> compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I
> care. But it really should align with a major revision #)

Splitting PHP in 3 independent parts could help solving the
backwards problem.

- Library (Functions, Methods)
- Virtual Machine (Zend Engine)
- Compiler for PHP 5.2, PHP 6, ...

             Library
                |
               VM                 
                |
         P-Code/Bytecode
            /   |      \ 
           /    |       \
         5.2    5.3    6.0 ... compiler


So a system could contain a compiler for each major
PHP version. Sourcecode written for PHP 5.2 will
use PHP compiler 5.2, sourcecode for PHP 6.0 will use
PHP compiler 6.0, ... No backwards problem for existing
code.

It's still necessary to update 5.2 code to use it
with the PHP 6.0 compiler but the existing code
does not prevent to use PHP 6.0 now for new scripts and
classes. And this is IMO easier then using (fast) CGI or
multiple instances of a webserver to have different
versions of PHP on one server.

There could also be different major versions of
the library.


tschuess
      [|8:) http://www.sven-drieling.de/

---

## #44023 — Christian Schneider — 2009-05-18T11:38:04+00:00

URL: https://externals.io/message/43935#44023 · In reply to: #43999

Michael Shadle wrote:
> 
> 
> > […]
> 
> True but aren't some changes in 6.0 at least (and possibly 5.3) going
> to require code changes? Or is it still going to be "legacy enough" ?

There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something *everybody* uses.

Apart from the fact that _REQUEST is not evil per se, the new setting
request_order turns it into something sane again...

So please let's end (at least the public) discussion here ;-)

- Chris

---

## #44026 — Michael Shadle — 2009-05-18T16:59:34+00:00

URL: https://externals.io/message/43935#44026 · In reply to: #44023

On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
<cschneid@cschneid.com> wrote:

> There's a big difference between changing some rare features (and no,
> 5.3 needs - almost no to - no changes with the code bases I know) and
> removing something *everybody* uses.
>
> Apart from the fact that _REQUEST is not evil per se, the new setting
> request_order turns it into something sane again...
>
> So please let's end (at least the public) discussion here ;-)

Not *everybody* uses it.

a) Once again I'll use python as an example, you -can- break backwards
compatibility to finally break free of certain stigmas

b) Would it be possible to tweak request_order so if it is blank, it
does not even create $_REQUEST? That I suppose would be good enough
for me.

---

## #44027 — Jani Taskinen — 2009-05-18T17:29:12+00:00

URL: https://externals.io/message/43935#44027 · In reply to: #44026

Michael Shadle wrote:
> On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
> <cschneid@cschneid.com> wrote:
> 
> > […]
> 
> Not *everybody* uses it.
> 
> a) Once again I'll use python as an example, you -can- break backwards
> compatibility to finally break free of certain stigmas

PHP != Python. PHP has lot more users. ;)

> b) Would it be possible to tweak request_order so if it is blank, it
> does not even create $_REQUEST? That I suppose would be good enough
> for me.

Just leave request_order empty in your php.ini and $_REQUEST will be 
empty. Now, please stop spamming the list about this issue.

--Jani

---

## #44028 — Rasmus Lerdorf — 2009-05-18T19:39:47+00:00

URL: https://externals.io/message/43935#44028 · In reply to: #44027

Jani Taskinen wrote:
> Michael Shadle wrote:
> > […]
> 
> PHP != Python. PHP has lot more users. ;)
> 
> > […]
> 
> Just leave request_order empty in your php.ini and $_REQUEST will be
> empty. Now, please stop spamming the list about this issue.

I think it defaults back to variables_order if you do that actually, but
you could set it to just "G" and then $_REQUEST will be the same as
$_GET which should also be fine for people who don't like to mix them.

-Rasmus