In PHP, what does $_REQUEST contain, how does request_order control it, and why do most codebases avoid it?

## How PHP builds $_REQUEST `$_REQUEST` is not a separate input source; it is a **merged copy** of other superglobals. PHP builds it like this: 1. Take the value of `request_order`. If it is not set, use `variables_order` instead. 2. Walk its letters from left to right. `G` merges `$_GET`, `P` merges `$_POST`, `C` merges `$_COOKIE`; other letters are ignored, and each source is merged at most once. 3. Each merge writes its keys into the result. When a key already exists, the **later** source overwrites it (nested arrays are merged recursively). So the order is also a precedence rule: with `"GP"`, a field present in both the query string and the POST body takes the POST value. ## Configuration values | Setting | `$_REQUEST` contains | Precedence | |---|---|---| | `request_order = "GP"` (both shipped php.ini files) | `$_GET`, then `$_POST` | POST wins | | `request_order = "PG"` | `$_POST`, then `$_GET` | GET wins | | `request_order = "GPC"` | Query, body and cookies | Cookies win | | `request_order` unset, built-in `variables_order = "EGPCS"` | Query, body and cookies | Cookies win | The last row is why the manual says `$_REQUEST` contains `$_GET`, `$_POST` and `$_COOKIE` "by default": the engine's own defaults include cookies, while the recommended ini files exclude them. The same code can therefore see different data on a server that ships no php.ini. ## Why codebases avoid it - **It erases provenance.** A handler that reads `$_REQUEST['cancel_booking']` cannot tell whether the value came from a submitted form, a URL someone was tricked into clicking, or a cookie. - **It weakens the GET/POST split.** An action intended only for POST also runs for `GET /bookings/cancel?cancel_booking=1`, which can be embedded in an image tag or a link on another site. CSRF defences such as tokens still matter, but accepting GET for a state change makes attacks easier. - **It depends on configuration.** Changing `request_order` or running without a php.ini changes which value wins, without any code change. - **Cookies can shadow form fields** when cookies are included: a cookie named like a form field silently overrides it. - **It hides intent from readers.** `$_POST['nights']` documents where the value is expected; `$_REQUEST['nights']` does not. ## What to use instead Read the source you expect, chosen by the method: ```php $input = match ($_SERVER['REQUEST_METHOD'] ?? 'GET') { 'POST' => $_POST, default => $_GET, }; ``` Frameworks go one step further and wrap the superglobals in a request object with separate accessors for query parameters, body parameters and cookies, which keeps the distinction explicit throughout the application. ## Removing $_REQUEST from an existing codebase A mechanical migration works in small, safe steps: 1. Search for `$_REQUEST` and list each handler that reads it. 2. For each handler, decide which method it serves; a form handler reads `$_POST`, a listing or search reads `$_GET`. 3. Where one handler serves both (a search form that also accepts links), read both explicitly and document the precedence you want. 4. Reject the unexpected method with a 405 response instead of silently accepting it. 5. Check whether any code relied on cookie values arriving through `$_REQUEST`; read those from `$_COOKIE` deliberately. To see what a given server actually does, `ini_get('request_order')` returns the effective value; an empty result means the directive is unset and `variables_order` is in charge. ## When $_REQUEST is harmless A read-only search endpoint that deliberately accepts a term either from a link or from a form can use `$_REQUEST` without risk, as long as the server's `request_order` is known and cookies are excluded. Even there, reading `$_GET` and `$_POST` explicitly is only one line longer and states the intent.