Суперглобальные переменные

OxPHP заполняет все стандартные суперглобальные переменные PHP до выполнения вашего скрипта, воспроизводя поведение, которое PHP-разработчики ожидают от традиционной серверной конфигурации. Значения доступны с первой строки вашего кода и не требуют какой-либо инициализации. Сузить это может лишь одна настройка; см. Отключение суперглобальных переменных.

$_SERVER

OxPHP формирует $_SERVER из входящего HTTP-запроса в соответствии со спецификацией CGI/1.1. Сначала импортируются переменные окружения процесса, затем задаются CGI-переменные, поэтому значения, специфичные для запроса, всегда переопределяют совпадающие по имени ключи окружения.

Стандартные переменные

Переменная	Описание	Пример
`SCRIPT_FILENAME`	Абсолютный путь в файловой системе к исполняемому PHP-скрипту	`/var/www/html/public/index.php`
`DOCUMENT_ROOT`	Корневой веб-каталог, задаваемый переменной окружения `DOCUMENT_ROOT`	`/var/www/html/public`
`SERVER_SOFTWARE`	Идентификатор сервера (содержит версию запущенного OxPHP)	`OxPHP/0.13.0`
`SERVER_PROTOCOL`	Согласованная версия протокола HTTP	`HTTP/2`
`REQUEST_METHOD`	HTTP-метод	`GET`
`REQUEST_URI`	Полный URI со строкой запроса	`/app?page=2`
`SCRIPT_NAME`	Путь исполняемого скрипта относительно `DOCUMENT_ROOT` — фронт-контроллер в режиме Framework, а не URI запроса	`/index.php`
`DOCUMENT_URI`	Псевдоним `SCRIPT_NAME`, для совместимости с nginx/PHP-FPM	`/index.php`
`PHP_SELF`	`SCRIPT_NAME` плюс `PATH_INFO`, если он присутствует, иначе равен `SCRIPT_NAME`	`/index.php/user/42`
`QUERY_STRING`	Часть URI, содержащая строку запроса (пустая строка при отсутствии)	`page=2`
`SERVER_NAME`	Имя хоста из заголовка `Host`	`example.com`
`SERVER_PORT`	Порт из заголовка `Host`	`8080`
`REMOTE_ADDR`	IP-адрес клиента	`172.17.0.1`
`REMOTE_PORT`	Номер порта клиента	`54321`
`HTTPS`	Устанавливается в `"on"`, когда соединение использует TLS; иначе отсутствует	`on`
`REQUEST_SCHEME`	`"https"` для TLS-соединений, иначе `"http"`	`https`
`CONTENT_TYPE`	Значение заголовка `Content-Type` (без префикса `HTTP_`)	`application/json`
`CONTENT_LENGTH`	Значение заголовка `Content-Length` (без префикса `HTTP_`)	`128`
`REQUEST_TIME`	Unix-время (целое число) начала запроса	`1738800000`
`REQUEST_TIME_FLOAT`	Unix-время с точностью до микросекунд	`1738800000.123456`
`GATEWAY_INTERFACE`	Строка версии CGI	`CGI/1.1`

Если заголовок Host отсутствует, SERVER_NAME по умолчанию принимает значение localhost, а SERVER_PORT — 80 (или 443 для TLS).

Заголовки HTTP-запроса

Все заголовки HTTP-запроса добавляются в $_SERVER с префиксом HTTP_. Имена заголовков приводятся к верхнему регистру, а дефисы заменяются подчёркиваниями — по соглашениям CGI/1.1:

text

Accept: text/html            -> HTTP_ACCEPT
X-Forwarded-For: 1.2.3.4    -> HTTP_X_FORWARDED_FOR
Authorization: Bearer abc    -> HTTP_AUTHORIZATION
Cookie: session=xyz          -> HTTP_COOKIE

Note

Content-Type и Content-Length появляются без префикса HTTP_ — как CONTENT_TYPE и CONTENT_LENGTH — как того требует спецификация CGI.

За обратным прокси

Когда настроен TRUSTED_PROXIES и узел, от которого поступил запрос, входит в доверенный набор, OxPHP перезаписывает следующие ключи $_SERVER из проброшенных заголовков (X-Forwarded-* или RFC 7239 Forwarded):

Переменная	Значение, когда узел доверенный	Значение в остальных случаях
`REMOTE_ADDR`	Самый правый недоверенный адрес из `X-Forwarded-For` / `Forwarded`; `CF-Connecting-IP` для запроса, цепочка перенаправления которого показывает, что он пришёл с пограничного узла Cloudflare, когда `TRUSTED_PROXIES` содержит `cloudflare`; непосредственный узел, когда проброшенные заголовки не дают адреса	IP непосредственного узла
`REMOTE_PORT`	Исходный порт клиента из записи `ip:port` в `Forwarded` или `X-Forwarded-For`, иначе `0`; порт узла, когда адрес не перезаписывается	Порт непосредственного узла
`HTTPS`	`"on"`, если `X-Forwarded-Proto: https`	Устанавливается только когда соединение с узлом использует TLS
`REQUEST_SCHEME`	`"https"` / `"http"` из `X-Forwarded-Proto`	На основе фактического состояния TLS
`SERVER_NAME`	Часть с именем хоста из `X-Forwarded-Host`	Часть с именем хоста из заголовка `Host`
`SERVER_PORT`	`X-Forwarded-Port`, иначе часть с портом из `X-Forwarded-Host`, иначе 443/80 по схеме	Часть с портом из `Host`, либо 443/80

Исходные ключи HTTP_X_FORWARDED_FOR, HTTP_X_FORWARDED_PROTO, HTTP_X_FORWARDED_HOST, HTTP_X_FORWARDED_PORT и HTTP_FORWARDED остаются в $_SERVER без изменений — доступны и перезаписанные значения, и исходные заголовки.

Когда адрес клиента перезаписывается, REMOTE_PORT — это исходный порт клиента, если запись, из которой взят адрес, его несёт (узел RFC 7239 Forwarded: for="ip:port" или запись ip:port в X-Forwarded-For), и "0" в противном случае: значение обнуляется, а не угадывается. Адрес, взятый из CF-Connecting-IP, тоже не несёт порта, поэтому REMOTE_PORT тогда равен "0", даже если в Forwarded порт есть. Когда проброшенные заголовки не дают адреса клиента (см. Извлечение IP-адреса клиента), ни REMOTE_ADDR, ни REMOTE_PORT не перезаписываются: оба остаются значениями непосредственного узла.

Когда TRUSTED_PROXIES не задан, перезапись не выполняется, и REMOTE_ADDR всегда равен непосредственному узлу — обычно это ваш балансировщик нагрузки, а не конечный клиент. Разбирать X-Forwarded-For вручную чревато ошибками (крайний левый или крайний правый адрес, отсутствие проверки доверия по CIDR); предпочтительнее настроить TRUSTED_PROXIES. См. Доверенные прокси, где описаны алгоритм доверия и синтаксис настройки.

Переменные контекста трассировки

Когда включена распределённая трассировка, OxPHP добавляет в $_SERVER переменные контекста трассировки:

Переменная	Описание	Пример
`OXPHP_TRACE_ID`	Идентификатор трассировки W3C для текущего запроса	`4bf92f3577b34da6a3ce929d0e0e4736`
`OXPHP_SPAN_ID`	Идентификатор спана для серверного спана OxPHP	`00f067aa0ba902b7`
`OXPHP_PARENT_SPAN_ID`	Идентификатор родительского спана от вышестоящего сервиса (пусто, если это корень)	`b9c7c989f97918e1`

Эти переменные присутствуют только когда приходит корректный заголовок traceparent или когда OxPHP генерирует новую трассировку. Если трассировка не настроена, эти ключи отсутствуют.

Отличия от PHP-FPM

Следующие переменные ведут себя иначе, чем в стандартной конфигурации PHP-FPM:

Переменная	Поведение
`SERVER_ADDR`	Не устанавливается. OxPHP не заполняет локальный IP-адрес сервера.
`PATH_INFO`	Устанавливается автоматически — см. Поведение PATH_INFO ниже.
`PATH_TRANSLATED`	Не устанавливается.
`PHP_AUTH_USER` / `PHP_AUTH_PW` / `AUTH_TYPE`	Не извлекаются из заголовка `Authorization`. Читайте `$_SERVER['HTTP_AUTHORIZATION']` напрямую.
`REDIRECT_STATUS`	Не устанавливается. OxPHP не использует внутренний механизм перенаправления.

Пример

php

<?php
$method  = $_SERVER['REQUEST_METHOD'];
$uri     = $_SERVER['REQUEST_URI'];
$ip      = $_SERVER['REMOTE_ADDR'];
$host    = $_SERVER['SERVER_NAME'];
$scheme  = $_SERVER['REQUEST_SCHEME'];  // "http" or "https"

// Read a custom header
$token = $_SERVER['HTTP_AUTHORIZATION'] ?? '';

// REMOTE_ADDR is already the real client IP when TRUSTED_PROXIES is configured.
// Without it, REMOTE_ADDR is the direct peer (usually a load balancer).
$clientIp = $_SERVER['REMOTE_ADDR'];

// Check TLS without checking the port
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') {
    // Secure connection
}

Поведение PATH_INFO

$_SERVER['PATH_INFO'] заполняется автоматически в зависимости от активного режима маршрутизации. Никакого флага для этого нет — прежняя переменная окружения SPLIT_PATH_INFO_ENABLED была удалена.

Режим маршрутизации	Когда устанавливается	Значение
Traditional (`ENTRY_FILE` не задан)	Только когда URI содержит `.php/` и префикс скрипта существует на диске	Хвост после сегмента скрипта
Framework (`ENTRY_FILE=index.php`)	Только когда запрос явно указывает входной файл с завершающим сегментом (`/index.php/extra`)	Хвост после входного файла, например `/news`
SPA (`ENTRY_FILE=index.html`)	Никогда — PHP выполняется только для точных `.php`-файлов, без PATH_INFO	—

SCRIPT_NAME всегда указывает на исполняемый скрипт (разрешённый файл относительно корневого каталога документов), поэтому при обычной маршрутизации PATH_INFO присутствует только тогда, когда SCRIPT_NAME является буквальным префиксом пути запроса. Когда запрос переписывается на фронт-контроллер, который в нём не назван (маршрут приложения, индекс каталога, запасной вариант при промахе по статике), PATH_INFO отсутствует, а исходный путь хранится в REQUEST_URI. (Запасной вариант PHP_DENY_PATHS — намеренное исключение: он устанавливает PATH_INFO равным исходному очищенному URI, чтобы запасной скрипт мог по нему маршрутизировать.)

Примеры режима Traditional

OxPHP сканирует URI слева направо в поисках первого сегмента .php, которому соответствует реальный файл на диске. Всё, что идёт после него, становится PATH_INFO:

URI запроса	Файл на диске	`SCRIPT_NAME`	`PATH_INFO`	`PHP_SELF`
`/app.php/user/42`	`app.php` существует	`/app.php`	`/user/42`	`/app.php/user/42`
`/index.php/api/v2/users`	`index.php` существует	`/index.php`	`/api/v2/users`	`/index.php/api/v2/users`
`/app.php`	`app.php` существует	`/app.php`	(отсутствует)	`/app.php`
`/missing.php/foo`	файл не найден	откат к `/index.php`	—	зависит от отката

Примеры режима Framework

Каждый нестатический запрос переписывается на index.php. PATH_INFO устанавливается только тогда, когда запрос явно указывает входной файл с завершающим сегментом; для маршрутов приложения исходный путь читается из REQUEST_URI.

URI запроса	`SCRIPT_NAME`	`PATH_INFO`
`/api/users`	`/index.php`	(отсутствует)
`/about.php`	`/index.php`	(отсутствует)
`/index.php/news/local`	`/index.php`	`/news/local`
`/index.php`	`/index.php`	(отсутствует)

Note

PATH_TRANSLATED не заполняется. На практике он используется редко и по умолчанию не устанавливается ни nginx, ни PHP-FPM.

$_GET

Параметры строки запроса автоматически разбираются из URI запроса.

php

<?php
// Request: GET /search?q=oxphp&page=2
$query = $_GET['q'];     // "oxphp"
$page  = $_GET['page'];  // "2"

Синтаксис массивов работает как ожидается:

php

<?php
// Request: GET /filter?tags[]=php&tags[]=async
$tags = $_GET['tags'];  // ["php", "async"]

Что видит filter_input(INPUT_GET, …)

filter_input(), filter_input_array() и filter_has_var() не читают $_GET, $_POST или $_COOKIE. Расширение filter хранит собственную копию разобранного ввода, и в постоянном воркере эту копию наполняет каждый запрос — а значит, каждый запрос должен её и возвращать, иначе значения строки запроса одного клиента, его сессионные cookies и поля тела остаются читаемыми для всех запросов, которые воркер обслужит после. OxPHP возвращает её в начале каждого запроса, поэтому эти три функции отвечают за тот запрос, который спрашивает, и ни за какой другой.

Режим воркеров добавляет одно ограничение. Если ваш запрос приостанавливается (sleep(), await, перехваченный вызов) и в этом окне на том же воркере выполняется другой запрос, хранилище становится его. Чтения после возобновления отвечают null, а не чужим вводом, — копии, которая была у вашего запроса, к тому моменту уже нет. Достаточно, чтобы другой запрос там начался или возобновился, — заканчиваться он не обязан. $_GET, $_POST и $_COOKIE путешествуют с запросом через приостановку и не затрагиваются, поэтому читайте их — или читайте функции filter до того, как приостановитесь.

Одному вызову приостанавливаться не разрешено вовсе. filter_input_array(), получившая массив определений по полям, читает хранилище по разу на поле, поэтому FILTER_CALLBACK, выполняющий ввод-вывод, работает, удерживая воркер на всю свою длительность, вместо того чтобы отдать его другому запросу, а явный Fiber::suspend() внутри такого колбэка выбрасывает исключение. Ожидание всё равно происходит — просто ждёт поток воркера, а не запрос, — поэтому медленный колбэк проявляется как задержка для всего, что стоит за ним в очереди, а после исчерпания своего бюджета ожидания эти стоящие в очереди запросы сбрасываются. Сколько это может длиться, определяет то, с чем разговаривает колбэк, а не сервер: обёртка потока сдаётся после default_socket_timeout (60 секунд из коробки), тогда как mysqlnd ждёт mysqlnd.net_read_timeout (сутки из коробки). Давайте такому вызову явный таймаут — а лучше выполняйте валидацию, обращающуюся к базе данных или кэшу, над значением уже после того, как filter_input_array() его вернула.

$_POST

OxPHP поддерживает два стандартных типа содержимого для отправки форм:

application/x-www-form-urlencoded — стандартные данные HTML-формы
multipart/form-data — загрузка файлов в сочетании с полями формы

php

<?php
// Request: POST /login
// Content-Type: application/x-www-form-urlencoded
// Body: username=admin&password=secret

$username = $_POST['username'];  // "admin"
$password = $_POST['password'];  // "secret"

Для JSON или других типов содержимого используйте вместо этого php://input:

php

<?php
// Request: POST /api/users
// Content-Type: application/json
// Body: {"name":"Alice","email":"alice@example.com"}

$data  = json_decode(file_get_contents('php://input'), true);
$name  = $data['name'];   // "Alice"
$email = $data['email'];  // "alice@example.com"

Note

filter_input(INPUT_POST, …) читает собственную копию тела в расширении filter, а не $_POST — что это за копия и сколько она живёт, см. в примечании под $_GET.

$_COOKIE

Куки разбираются из заголовка запроса Cookie.

php

<?php
// Request with: Cookie: session=abc123; theme=dark
$session = $_COOKIE['session'];  // "abc123"
$theme   = $_COOKIE['theme'];    // "dark"

Note

Куки с префиксом __oxp_ зарезервированы для внутренних плагинов OxPHP. Они удаляются из заголовка Cookie до того, как он достигнет PHP, и не появляются в $_COOKIE.

Note

filter_input(INPUT_COOKIE, …) читает собственную копию cookies в расширении filter, а не $_COOKIE — что это за копия и сколько она живёт, см. в примечании под $_GET.

$_FILES

Загруженные файлы, отправленные через multipart/form-data, заполняют массив $_FILES стандартной для PHP структурой:

php

<?php
// $_FILES['avatar'] structure:
// [
//     'name'     => 'photo.jpg',       // Original filename sent by the client
//     'type'     => 'image/jpeg',      // MIME type declared by the client
//     'tmp_name' => '/tmp/phpAb12Cd',  // Temporary file path on the server
//     'error'    => 0,                 // UPLOAD_ERR_OK (0 means no error)
//     'size'     => 204800,            // File size in bytes
// ]

if ($_FILES['avatar']['error'] === UPLOAD_ERR_OK) {
    $tmp  = $_FILES['avatar']['tmp_name'];
    $name = basename($_FILES['avatar']['name']);
    move_uploaded_file($tmp, "/uploads/$name");
}

$_REQUEST

$_REQUEST — это объединённый массив из $_GET, $_POST и $_COOKIE, формируемый PHP согласно INI-директиве request_order, а если request_order не задана — согласно variables_order. Само слияние следует правилам PHP без изменений: источники объединяются в том порядке, в котором их перечисляет директива, и более поздний источник перезаписывает ключ, заданный более ранним.

Cookie входят в массив, и они побеждают

Образы OxPHP не загружают php.ini: php.ini-production и php.ini-development лежат в /usr/local/etc/php без дела (см. Установка). Поэтому request_order не задана, и PHP откатывается к встроенному значению variables_order, "EGPCS": сначала GET, затем POST, затем COOKIE. Значит, cookie заменяет одноимённое значение из строки запроса или тела; если обе стороны — массивы (k[a] в теле, k[b] в cookie), они объединяются поключно по тому же правилу.

Знакомое по конфигурациям PHP-FPM request_order = "GP" берётся из образцов php.ini-production и php.ini-development, а не из самого PHP. Чтобы исключить cookie, задайте его в ini-файле, загружаемом при старте, например в /usr/local/etc/php/conf.d/zz-request-order.ini со строкой request_order = "GP". ini_set() не может изменить эту директиву во время выполнения.

php

<?php
// POST /form?action=preview with body action=submit
$action = $_REQUEST['action'];  // "submit" — POST overrides GET

// Same request, also carrying the header "Cookie: action=delete"
$action = $_REQUEST['action'];  // "delete" — the cookie overrides both

Режим воркеров

$_REQUEST пересобирается для каждого запроса. Обычно PHP строит его лениво, один раз — когда впервые загружается скрипт, который его упоминает, — что в постоянном воркере означало бы, что каждый последующий запрос читает параметры первого. OxPHP принудительно выполняет пересборку, поэтому объединённый массив всегда описывает обслуживаемый запрос.

$_ENV

$_ENV содержит окружение процесса. В традиционном режиме она ведёт себя ровно как в PHP-FPM: PHP заново заполняет её из окружения при каждом запросе, с учётом variables_order.

Режим воркеров её закрепляет. Воркер инициализируется один раз, а загрузчики .env (vlucas/phpdotenv, symfony/dotenv, Env в Laravel) пишут свои значения прямо в $_ENV, не трогая окружение процесса. Перезаполнение $_ENV на каждый запрос стирало бы конфигурацию приложения начиная со второго запроса, поэтому в режиме воркеров массив, однажды возникнув, сохраняется на всю жизнь воркера. Записи, сделанные туда вашей инициализацией, остаются видимыми каждому запросу, который этот воркер обслуживает, — как и любая другая запись в него; что это означает внутри обработчика запроса, объясняет предупреждение под примером.

php

<?php
// bootstrap, before oxphp_worker()
Dotenv\Dotenv::createImmutable(__DIR__)->load();   // writes into $_ENV

oxphp_worker(function () {
    echo $_ENV['DATABASE_URL'];  // still there on request 10_000
});

В режиме воркеров $_ENV — состояние воркера, а не запроса

Механизм лишь закрепляет массив, поэтому не отличает запись из инициализации от записи из обработчика: $_ENV['tenant_id'] = $request->tenant(); внутри обработчика запроса остаётся в $_ENV до конца жизни воркера. Её читает каждый последующий запрос, который обслуживает этот воркер. Читает и запрос, который воркер берёт в работу, пока записавший запрос припаркован в одной из точек приостановки, потому что $_ENV намеренно не входит в состояние, которое приостановленный запрос уносит с собой, и тогда оба читают один и тот же массив. Ни об одном из этих случаев не сообщается. Ни предупреждения, ни записи в логе не появляется; запрос просто читает значение, которое задал другой запрос.

Пишите в $_ENV из инициализации и больше ниоткуда. Значение на запрос храните там, что пересобирается на каждый запрос. $_SERVER как раз такой и переносится вместе со своим запросом через приостановку. Подойдёт и всё, что ваш фреймворк привязывает к запросу, но проверьте, что оно привязано именно к запросу, а не к воркеру; привязка в контейнере или стек запросов, настроенные один раз при инициализации, — это состояние воркера с тем же охватом, что и у $_ENV. Подходит и контейнер атрибутов у собственного объекта запроса OxPHP, если вы передаёте этот объект дальше: oxphp_http_request() при каждом вызове строит новый Request, а вместе с ним — новый, пустой контейнер.

Что видит filter_input(INPUT_ENV, …)

filter_input(INPUT_ENV, …), filter_input_array(INPUT_ENV) и filter_has_var(INPUT_ENV, …) в режиме воркеров читают окружение процесса. Они не читают $_ENV, поэтому значений, записанных туда — вашей инициализацией или чем-либо ещё, — среди них нет. Так PHP ведёт себя везде, потому что запись в $_ENV даёт массиву собственную копию, а расширение filter продолжает читать снимок окружения, сделанный движком. Режим воркеров добавляет один нюанс: этот снимок — тот, что был сделан при первом построении $_ENV на воркере, поэтому вызова putenv(), сделанного позже, в нём тоже нет. getenv() читает живое окружение и не затрагивается; $_ENV содержит значения процесса плюс всё, что PHP на этом воркере в неё записал. Всё это касается только INPUT_ENV: INPUT_GET, INPUT_POST и INPUT_COOKIE читают собственное хранилище внутри расширения filter, описанное в примечании под $_GET выше.

Закрепление опирается на PHP-умолчание auto_globals_jit=1. При auto_globals_jit=0 PHP заново заполняет $_ENV из окружения процесса при каждом запросе, прежде чем какое-либо расширение сможет вмешаться, и значения загрузчика .env в режиме воркеров не выживут.

php://input

Необработанное тело запроса доступно через поток php://input. Это стандартный способ читать полезную нагрузку JSON, XML или любой тип содержимого, отличный от отправки форм.

php

<?php
$body = file_get_contents('php://input');
$data = json_decode($body, true);

php://input можно перематывать и читать несколько раз в рамках одного запроса.

Note

php://input пуст для запросов multipart/form-data. Для них используйте $_POST и $_FILES.

Отключение суперглобальных переменных

Задайте SUPERGLOBALS_ENABLED=false, чтобы OxPHP перестал описывать запрос для PHP: CGI-переменные и переменные HTTP_* не регистрируются, а строка запроса не передаётся на разбор. Для доступа к данным запроса используйте вместо этого HTTP Request API (oxphp_http_request()).

bash

SUPERGLOBALS_ENABLED=false # the $_SERVER request keys and $_GET are not built

Затрагивает она меньше этих массивов, чем подсказывает название. Тело запроса и заголовок Cookie передаются PHP в любом случае, поэтому всё, что PHP из них строит, на месте, как обычно:

Что	При `SUPERGLOBALS_ENABLED=false`
`$_GET`	Пуст
`$_SERVER`	Во время запроса — только четыре ключа: `REQUEST_TIME`, `REQUEST_TIME_FLOAT`, `argc` и `argv`, все регистрирует сам PHP, а не сервер. `REQUEST_METHOD`, `REQUEST_URI`, ключи `HTTP_` и окружение процесса отсутствуют. Режим воркеров инициализируется иначе:* код выше `oxphp_worker()` выполняется до любого запроса и видит `$_SERVER`, построенный так, будто настройка включена, включая всё окружение процесса, плюс заглушку `REQUEST_URI` со значением `/`
`$_POST`, `$_FILES`, `$_COOKIE`	Заполняются как обычно
`$_REQUEST`	Заполняется и объединяется PHP как всегда (см. `$_REQUEST`); отсутствует лишь то, что внёс бы `$_GET`
`$_SESSION`	Заполняется модулем сессий PHP, когда запрос начинает сессию, а не SAPI
`php://input`	Поток, а не суперглобальная переменная; читается как обычно
`header()`, `headers_list()` и т. д.	Функции SAPI, а не суперглобальные переменные
`session_start()` и другие функции `session_*()`	Нативные функции PHP
`oxphp_http_request()`	Доступна; отвечает каждый метод, включая `query()` и `payload()`

Маршрутизация по REQUEST_URI

Код, который маршрутизирует по $_SERVER['REQUEST_URI'], при этой настройке ничего там не находит и должен читать oxphp_http_request()->path(). В точке входа воркера это касается обработчика. Инициализация над ним видит заглушку /, описанную в таблице, и это тоже не настоящий маршрут.

Текущую настройку можно проверить во время выполнения:

php

if (!oxphp_superglobals_enabled()) {
    $request = oxphp_http_request();
    $page = $request->query('page', 1);
}

Промпты для вашего агента

Эти промпты рассчитаны на агента с подключённым MCP-сервером документации OxPHP — нужные страницы он прочитает сам.

prompt

Проверь чтения суперглобальных переменных в моём коде на то, что различается между OxPHP и PHP-FPM. Прочитай страницу `php/superglobals` через MCP-сервер документации OxPHP.
Поищи в моём приложении чтения `$_SERVER['PHP_AUTH_USER']`, `SERVER_ADDR` и `PATH_TRANSLATED` и код Basic-аутентификации, который ждёт их уже разобранными, и скажи мне, какие чтения надо поменять и на что.

prompt

Моё приложение в режиме воркеров OxPHP теряет значения, прочитанные через `filter_input()`. Прочитай страницу `php/superglobals` через MCP-сервер документации OxPHP.
Найди в моём коде вызовы `filter_input()` и `filter_input_array()`, которые встают на паузу на вводе-выводе или на приостановленном файбере, и скажи мне, какие из них подвержены описанной на странице гонке режима воркеров, когда возобновлённый запрос читает хранилище чужого запроса.

См. также

HTTP Request API -- типизированный, лениво загружаемый объект запроса как альтернатива суперглобальным переменным
Функции PHP -- oxphp_request_id(), oxphp_worker_id() и другие функции расширения
Режим воркеров -- как суперглобальные переменные обновляются между запросами воркера
Справочник по конфигурации -- DOCUMENT_ROOT и другие переменные конфигурации сервера