URL values with $_REQUEST in PHP

I开发者_如何学运维f I am passing some parameters in the URL is it a bad practise to retrieve them using $_REQUEST super globa as opposed to $_GET super

---

Well, since you expect them to be coming in as GET variables only, why use $_REQUEST and not $_GET?

The problem with $_REQUEST is that if there are variables of GET, POST and/or COOKIE, one will override the other in that superglobal. It's semi-predictable what values you end up getting if you try to access $_REQUEST.

---

There are several issues with using $_REQUEST.

1. It can be confusing to your future self and other maintainers as to where the data is coming from.
2. It can cause collisions, and create hard-to-find bugs in which you are getting the wrong data (because $_REQUEST covers $_GET, $_POST, and $_COOKIE).

There may be others that I don't remember right now, too.

So yes, it's bad practice.

---

No, it's not bad practice. The only thing is that $_REQUEST will contain values passed in GET and POST commands, and COOKIES values. So if you want to process only values passed in the URL, you will probably want to use $_GET...

---

It is possible to set the order of GET POST COOKIE vars in php.ini so if you have a POST or COOKIE var with the same name, the GET var won't be the active one in REQUEST.

It's really best to just use the appropriate superglobal for the type of data you're accessing.. in your case, $_GET

And otherwise you (or anyone else) don't know were the data came from when using $_REQUEST

---

One benefit to $_GET and $_POST are that you know exactly how your script received the parameters. It also keeps them in separate namespaces, so that $_GET['foo'] will always be distinct from $_POST['foo'], which $_REQUEST does not do.

In the end, it is a design choice that is up to you, but one day down the road, you'll look back and be glad that you used $_GET instead of $_REQUEST (unless you had a specific reason not to). One thing to remember though, as always: $_GET, $_POST and $_REQUEST all possibly contain user-manipulated data, and so SHOULD NOT be trusted. Always sanitize!

---

It's usually not a problem. Typically you want to hava a form/API accessible with any method. Then $_REQUEST is the best choice. You should differentiate on the functionality. If an access modifies data, then make it dependend on $_POST. If an access is strictly for querying, then force it to use $_GET only.

There are security implications of using $_REQUEST (the cookies fixation issue), but they are usually blown out of proportion. It's outdated for current PHP configurations anyway. So with a grain of salt - there were a few former discussions to the topic:

• What's wrong with using $_REQUEST[]?
• Why should I use $_GET and $_POST instead of $_REQUEST?
• Does $_REQUEST have security problem?