I have a form a user can enter their name, then it will add it to $message to be sent in an email.
Is it better to use $_POST or $_REQUEST?
Here is a snippet of using $_REQUEST
$message.= "Name: ".$_REQUEST["fname"]." ".$_REQUEST["mname"]." ".$_REQUEST["lname"]."\n";
doesn't matter which one you use. just make sure you use some form of security with forms.
The answer is: It depends on how you want it to be used.
If you're using $_POST, that means it can only come in via POST.
If you're using $_REQUEST, that means you accept POST, GET (and COOKIE, but it's mainly the first two we're interested in).
For something like this, $_POST would probably be neater, but if you were making a search engine, allowing to set up a search URL would probably be a good idea. However, you might want to allow for a ton of special parameters to narrow down the search, and if that can take up a lot of URL space, you'll probably want to allow POSTDATA as well.
As Dylan mentions, keep in mind that neither is a replacement for any kind of security.
_POST if data is being updated somewhere (i.e. if the action has a side-effect), _REQUEST otherwise, and if you don't care whether or not the data comes via GET, POST, or any other method.
My approach used to be to use $_REQUEST for everything which I think is a big mistake. Lately, I've been trying to be more diligent about using GET only for read-requests & POST only for write-requests.
To that end, I think using $_GET for GET requests & $_POST for POST requests makes my intent much more clear in my code.
Unless you have a good reason to do otherwise (such as the search engine mentioned by Michael), it's probably better to use $_GET and $_POST for their respective methods instead of $_REQUEST, to avoid any ambiguity or confusion over possibly having the same argument name in the GET and POST data.
I just listened to Security Now episode #166 which was all about cross-site request forgery, and in it, Steve makes a good case for using $_POST for forms rather than $_REQUEST. (Indirectly, he doesn't talk about PHP itself, but does say that you shouldn't accept both GET and POST for forms.) The reason is that it's easy to use GET requests for CSRF attacks but not so easy to use POST.
Using $_POST itself doesn't eliminate the possibility of CSRF attacks, but it does reduce it. Steve also suggests using a cryptographically strong pseudo-random hidden field in the request that will eliminate the possibility of "blind" requests.
The only time I use $_REQUEST is when I need to be able to support data from either $_POST or $_GET.
For example, if I have a form that's supposed to modify a record, I might initially pass the record ID in the url as id=X. So when first loading the form, I could use $_GET['id'] to figure out what record we're trying to modify.
However, when submitting the modify operation, the form should be POSTed, since it will be changing data and is not idempotent. In this case, the record ID would be accessible as $_POST['id'] when processing the form submission.
But what happens if there's an error in the form submission and I need to reload the form with a helpful error message? In this case, the form generation code needs to figure out what record to use by looking at the POSTed id, which is not in the URL.
In cases like this, I would use $_REQUEST['id'] in the form display logic, so that it could support either scenario. But for form processing, I would use $_POST['id'] for strict checking.