PHP $_REQUEST

What is $_REQUEST?

$_REQUEST merges the contents of $_GET, $_POST, and $_COOKIE into a single array, so a script that reads from $_REQUEST doesn't need to know in advance which method delivered the data — convenient for a quick prototype, less so once you care about being explicit.

Example: What is $_REQUEST?

<?php
// Set `$_GET['q']` to "search term"
$_GET['q'] = "search term";
// Print `$_REQUEST['q']` to the output
echo $_REQUEST['q'];
?>

Reading GET Data via $_REQUEST

Reading $_REQUEST[q] for a value that was actually sent via the URL query string works exactly the way reading it from $_GET[q] would — $_REQUEST simply folds $_GET's contents in alongside the others, acting as a catch-all fallback.

Example: Reading GET Data via $_REQUEST

<?php
// Set `$_GET['q']` to "php tutorials"
$_GET['q'] = "php tutorials";
// Print `$_REQUEST['q']` to the output
echo $_REQUEST['q'];
?>

Reading POST Data via $_REQUEST

The same applies to form data sent via POST: $_REQUEST[username] picks it up just as $_POST[username] would.

The convenience is that your code doesn't have to branch on which method was used — the tradeoff is that it also can't tell which method was used just by looking at $_REQUEST.

Example: Reading POST Data via $_REQUEST

<?php
// Set `$_POST['username']` to "Alice"
$_POST['username'] = "Alice";
// Print `$_REQUEST['username']` to the output
echo $_REQUEST['username'];
?>

Variables Precedence in _REQUEST

If a GET parameter and a POST parameter share the same key, which one wins inside $_REQUEST is decided by PHP's request_order (or the older variables_order) setting in php.ini — not by your code — which makes the outcome depend on server configuration rather than anything visible in the script itself.

Example: Variables Precedence in _REQUEST

<?php
$_GET['key'] = "from-get";
$_POST['key'] = "from-post";
// Which one $_REQUEST['key'] holds depends on php.ini's request_order setting
echo $_REQUEST['key'];
?>

Limitations and Security

Because $_REQUEST can't distinguish a GET request from a POST one, code that relies on it can be tricked into accepting a state-changing action via a simple crafted URL instead of a real form submission.

Reaching for $_GET or $_POST explicitly avoids that entire class of confusion.

Example: Limitations and Security

<?php
// A crafted URL like ?delete_account=1 could trigger this if code trusts $_REQUEST
$_GET['delete_account'] = 1;
if (isset($_REQUEST['delete_account'])) {
    echo "This should require $_POST, not any $_REQUEST source.";
}
?>