Give a worker request the filter input of nobody but itself - #304

What was wrong

In worker mode, filter_input(), filter_input_array() and filter_has_var() answered with other requests' query values, session cookies and body fields.

For INPUT_GET, INPUT_POST and INPUT_COOKIE those functions do not read the superglobals. ext/filter keeps a parsed copy of its own in its module globals, filled by the SAPI input filter every time the engine rebuilds one of those superglobals, and emptied when a request starts up. A worker starts up once — per worker, not per request — while the refill happens on every request. Filled per request and emptied per worker, the copy accumulated for the life of the process.

Measured on a single worker, second request carrying no query string, no cookie and no body:

filter_input(INPUT_GET,    'oxfilter_token')  expected null, got 'seed-query-value'
filter_input(INPUT_COOKIE, 'oxfilter_sid')    expected null, got 'seed-session-id'
filter_input(INPUT_POST,   'oxfilter_pw')     expected null, got 'seed-body-secret'
filter_input_array(INPUT_POST)                expected null, got ['oxfilter_pw','oxfilter_user']

$_GET, $_COOKIE and $_POST were empty throughout, exactly as they should have been — so the two ways of reading input disagreed, and the wrong one was the API applications reach for because it is the safe way to read input. Nothing was logged and no error was raised.

Traditional, framework and SPA serving were never affected: there each request starts up on its own, which is what empties the copy.

What changed

The copy is given back at the start of every request, before the rebuild that refills it. It is released through ext/filter's own request shutdown, reached via module_registry, rather than through sapi_module.input_filter_init: that public hook only ZVAL_UNDEFs the arrays, while what releases them is the module's RSHUTDOWN — which a worker runs once. Calling the public hook per request would have traded a data leak for one orphaned hash table per input type per request, in a pool given back only when the worker exits.

The same leak had a second path under fiber multiplexing, since the copy is one set of arrays per thread rather than per request: a request served while another was parked read the parked one's input, and the parked one read that request's after resuming. A resume now gives the copy back too, but only when something else has owned it in the window — a generation counter parked with the fiber answers that. An ordinary pause with nothing else running on the worker costs a request nothing: it finds its own input where it left it.

filter_input_array() given a per-field definition array can no longer suspend the calling fiber. That form reads the storage through the module-globals slot itself and re-reads it once per field, with userland in between whenever a field asks for FILTER_CALLBACK — so a request parked inside such a callback came back to memory the next request's reset had released. Measured before the guard: the field read after the callback answered null, from a lookup in a released hash table. The handler now holds zend_fiber_switch_block() for that form alone, which every suspend point honours by taking its blocking path.

Every other way in reaches the original handler untouched: filter_has_var() runs no userland, and filter_input() and filter_input_array() without a definition array copy the slot before any filter runs — ZVAL_DUP is their only read of it, identically on 8.4, 8.5 and master — so blocking there would protect nothing while costing a userland fiber scheduler a suspension point for the length of the call.

The reset refuses to run while such a call is reading, and logs why. That the guard suffices rests on an invariant nothing enforces — that every suspend point checks zend_fiber_switch_blocked() — and a fifth suspend point added without that check would park the frame silently, leaving the next request's reset to free the array it holds. A thread-local reader count turns that from a use-after-free with no witness into a log line and a skipped reset. ZEND_ASSERT was not an option here: the images run a release build of PHP, where it compiles to nothing.

Hooked sleep() and usleep() no longer return instantly where the fiber cannot be suspended. They are meant to fall back to the native builtin there, as the hooked socket read and stream_select() already do, and instead skipped the wait entirely: a throttle stopped throttling and a backoff became a spin, in microseconds and with nothing logged. Reachable before this change from a declare(ticks) handler, from pcntl's signal dispatch, while a request's input is being built, and under a userland fiber scheduler. Measured: usleep(300000) inside a guarded callback took 1.0e-5 s.

Boundaries this documents

Both are worker-mode only and are written up in docs/php/superglobals.md and the changelog entry:

• Input read through the filter API is not readable after a pause that another request ran in. $_GET, $_POST and $_COOKIE travel with the request and are what to read after a suspension.
• A FILTER_CALLBACK that does I/O holds the worker thread for its duration instead of multiplexing, so it becomes latency for whatever is queued behind it, and past QUEUE_WAIT_TIMEOUT_MS those queued requests are shed with 529. How long that can go on is set by whatever the callback is talking to and not by the server: default_socket_timeout is 60 seconds out of the box, mysqlnd.net_read_timeout a day. Validation that reaches a database or a cache is better run on the value after filter_input_array() has returned it.

Tests

Four lines in the hooks profile, one worker: a POST with a query string and a cookie, a clean GET that must see none of it, a suspension covered from both sides through an inner self-request, and a FILTER_CALLBACK that parks with that inner request waiting. Each fails on a build without the matching half of the fix.