This question already has an answer here:
-
What's wrong with using $_REQUEST[]?
14 answers
Besides the fact that $_REQUEST
reads from cookies, are there any reasons why I should use $_GET
and $_POST
instead of $_REQUEST
? What are theoretical and practical reasons for doing so?
I use $_REQUEST when I just want certain data from the user to return certain data.
Never use $_REQUEST when the request will have side effects. Requests that produce side effects should be POST (for semantic reasons, and also because of basic CSRF stuff, a false img tag can hit any GET endpoint without a user even knowing).
$_GET should be used when GETing or POSTing to a page will produce different results.
Besides the fact that $_REQUEST reads from cookies
Besides the fact that this is undefined (It's configurable on a per-installation level), the problem using $_REQUEST
is that it over-simplifies things. There is (or should be) a semantic difference between a GET request and a POST request. Thus it should matter to your application if you get input from one source or the other. This is how the HTTP protocol is defined, so by ignoring it, you are undermining the protocol, which makes your application less interoperable. It's the same type argument that can be made for using semantic HTML markup, rather than presentation-oriented markup. Or more generally, following the intentions of a protocol rather than just doing whatever works in the concrete situation.
You already gave one of the answers, so I'll give another:
It's more of a stylistic choice. For instance, you don't usually want information that changes state on the server to be cacheable, so you probably want to restrict it to $_POST
variables.
The usage of $_REQUEST opens some attack vectors to your application where variables could be overwritten where you wouldn't want it to happen.
Also consider the order GPC (Get, Post, Cookie) on which the $_REQUEST will get filled.
i.e. a request with:
$_GET['foo'] = 'bar'
$_POST['foo'] = 'baz'
will result in
$_REQUEST['foo'] == 'bar'
the often-mentioned insecurity of $_REQUEST is bogus. all these are ways to get data from the user, which has a non-secured machine. you always have to sanitise the input, so there's no real security advantage from using either one.
it's only significant if you have different uses for values with the same name on different channels. in that case, you should rename some of them anyway.
HTTP GET is semantically meant to be used to fetch a page, while POST can be argued that when used, you'd expect that some kind of state is changed.
For example, there's an expectation that using GET with the same parameters multiple times yield the same results, while using POST, they may not.
Not using POST when you should yield to problems. I think the Ruby on Rails AJAX libraries used GET instead of POST, and lead to a lot of data being lost when being touched upon by web spiders.
Hence, you should probably avoid using $_REQUEST. You should know the purposes of what the page does, and decide on how to answer a GET request, and how to answer a POST request.
Here's one I've just found: When and why should $_REQUEST be used instead of $_GET / $_POST / $_COOKIE?.
I'm sorry I didn't find it sooner, so I wouldn't have asked the question...