$_REQUEST and $_SERVER

Pageturn's order script already reads $_POST and asks $_SERVER for the request method. PHP fills in a few more of these superglobals on every request. Two of them come up constantly: $_REQUEST, which is convenient and usually a mistake, and $_SERVER, which describes the request itself and deserves careful handling.

The rule

Read input from the source you expect; treat request details as claims.

$_REQUEST merges several sources into one array: $_GET, $_POST and, depending on configuration, cookies. When the same name appears in more than one, the server's request_order setting decides which one wins.

That vagueness is the problem. An action that should only happen on a POST can be triggered by a plain link with ?qty=50, and a cookie can silently override a form field. Read $_GET or $_POST directly, so the code states where the data must come from.

$_SERVER holds information about the request and the environment:

The keys beginning with HTTP_ are copied from the request headers, and the client writes those headers. A script can send any User-Agent or Host it likes. So:

• Use REQUEST_METHOD freely for branching; an unexpected value just fails your checks.
• Treat HTTP_* values, REQUEST_URI and PHP_SELF as untrusted text: escape them before printing them into a page, and never use them to decide who someone is.
• REMOTE_ADDR comes from the network connection, so it is harder to fake, but behind a proxy it is the proxy's address.

Some keys do not exist in every setup, for example when PHP runs from the command line, so read them with ?? too.

The shortcut

For every superglobal read, ask "who wrote this value?" The visitor, directly or through headers → validate and escape. The server's own configuration → generally safe.

Drills

Answer fast — trust the rule.

Remember

• Read input from the source you expect; treat request details as claims.
• Shortcut: ask "who wrote this value?" before trusting it.
• Trap: $_REQUEST blurs sources, and HTTP_* keys come straight from the visitor.