Middleware и конвейер запроса — бесплатный тест онлайн

Вопрос 1 из 30

Каков основной контракт PSR-15 middleware?

final class RequestIdMiddleware implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        return $handler->handle($request);
    }
}

Получить Response от предыдущего слоя и вернуть логический признак успеха Принять строковое имя маршрута и самостоятельно вызвать нужный контроллер Изменить переданный request на месте и завершиться без возвращаемого значения Получить ServerRequest и RequestHandler, вернуть Response Получить объект соединения и вернуть данные, которые позже превратятся в Response

Вопрос 2 из 30

Что означает короткое замыкание?

if ($request->getHeaderLine('Authorization') === '') {
    return new JsonResponse(['error' => 'unauthorized'], 401);
}
return $handler->handle($request);

Middleware возвращает ответ, не вызывая следующий handler Middleware пропускает входной request, но прерывает обработку уже на обратном пути Один и тот же request запускается по цепочке второй раз для проверки результата Конвейер завершает PHP-процесс до формирования корректного Response Middleware вызывает handler, но заменяет полученный ответ пустым объектом

Вопрос 3 из 30

Почему next/handler нельзя вызывать дважды?

$first = $handler->handle($request);
$second = $handler->handle($request);
return $second;

PSR-15 объединит оба ответа и выполнит побочные эффекты только один раз Второй вызов допустим, если первый Response не содержит тела Повторный вызов затронет лишь чтение request, поскольку handler обязан быть чистым Два вызова нужны, чтобы middleware мог измерить среднее время выполнения Бизнес-операция и побочные эффекты могут выполниться повторно

Вопрос 4 из 30

Как измерить время всего внутреннего конвейера?

$start=hrtime(true);
$response=$handler->handle($request);
$metrics->observe((hrtime(true)-$start)/1e9);
return $response;

Измерить только время создания middleware до передачи ему request Поставить таймер внутри конечного handler, не охватывая внутренние слои Вызвать handle дважды и считать разницу между результатами временем конвейера Замерить время до и после единственного вызова handle Сложить число middleware с временем формирования тела Response

Вопрос 5 из 30

Что лучше вынести из middleware авторизации?

Проверку наличия и формата credentials до вызова следующего слоя Извлечение bearer token из стандартизованного заголовка запроса Преобразование отсутствующих credentials в ответ со статусом 401 Добавление установленной личности в атрибут нового request Предметную проверку доступа, требующую доменных данных

Вопрос 6 из 30

Что делает withAttribute в неизменяемом request?

$requestWithUser = $request->withAttribute('user', $user);
return $handler->handle($requestWithUser);

Сохраняет значение в cookie, доступную последующим запросам Добавляет одноимённый заголовок к будущему Response Записывает атрибут в исходный request и возвращает ту же ссылку Возвращает новый объект запроса с атрибутом Меняет request на месте только при передаче скалярного значения

Вопрос 7 из 30

Почему хранить currentUser в static-поле опасно для долгоживущего worker?

final class RequestContext
{
    public static ?User $currentUser = null;
}

RequestContext::$currentUser = $authenticatedUser;

Worker не поддерживает объекты Поле автоматически очищается до middleware Пользователь станет readonly Static запрещён в PHP Состояние может перейти между запросами

Вопрос 8 из 30

Что лучше для request_id?

$requestId = $request->getHeaderLine('X-Request-Id');
if (!preg_match('/^[a-f0-9-]{16,64}$/i', $requestId)) {
    $requestId = bin2hex(random_bytes(16));
}
return $handler->handle($request->withAttribute('request_id', $requestId));

Всегда принимать любое присланное клиентом значение без проверки формата Хранить идентификатор только в пользовательской cookie и не передавать в журнал Принять доверенный ID либо создать новый и передать дальше Создавать новый идентификатор в каждом middleware, чтобы различать слои Использовать идентификатор записи из первого SQL-запроса внутри обработчика

Вопрос 9 из 30

Как избежать конфликтов атрибутов?

Полагаться на порядок алфавита Писать атрибуты в $_POST Уникальные ключи или типизированный объект контекста Сериализовать request после каждого слоя Все слои используют ключ data

Вопрос 10 из 30

Что произойдёт с атрибутом uid, если результат withAttribute() не передать дальше и продолжить использовать исходный request?

$request->withAttribute('uid',42);
var_dump($request->getAttribute('uid'));

Атрибут появится в исходном объекте после завершения текущего метода Атрибут сохранится, но будет доступен только на обратном пути конвейера Исходный request получит значение null вместо переданного uid Атрибута не будет без передачи нового request Метод withAttribute выбросит TypeError из-за неизменяемости request

Вопрос 11 из 30

Где ставить middleware неожиданных ошибок?

try {
    return $handler->handle($request);
} catch (Throwable $error) {
    return $this->errors->toResponse($error);
}

В предметной сущности, которая первой обнаруживает любое исключение Снаружи большинства слоёв, чтобы охватить их Throwable После отправки заголовков клиенту, чтобы не влиять на успешные ответы Сразу после конечного handler, чтобы ошибка уже была преобразована в Response Внутри шаблона 500, где доступно окончательное представление ошибки

Вопрос 12 из 30

Почему нельзя ловить Throwable и всегда возвращать 404?

try {
    return $handler->handle($request);
} catch (Throwable $error) {
    return new JsonResponse(['error' => 'not_found'], 404);
}

Любое исключение в middleware по стандарту означает отсутствие маршрута Код 404 автоматически заставит инфраструктуру повторить временно упавший запрос После преобразования в 404 исходное исключение всё равно полностью видно в HTTP-ответе Клиенту полезнее всегда получать одинаковый статус, чем различать классы ошибок Так программные дефекты маскируются под отсутствие ресурса

Вопрос 13 из 30

Что делать с деталями исключения?

try {
    return $handler->handle($request);
} catch (Throwable $error) {
    $eventId = bin2hex(random_bytes(8));
    $logger->error('Unhandled request error', ['event_id' => $eventId, 'exception' => $error]);
    return new JsonResponse(['error' => 'internal_error', 'event_id' => $eventId], 500);
}

Подробности — в журнал, клиенту — безопасную ошибку Записать детали в заголовок Location, чтобы их мог прочитать только оператор Скрыть и от клиента, и от журнала тип исключения, оставив только общий код Передать исходный message без фильтрации, если ответ имеет статус 500 Вернуть клиенту полный stack trace, но удалить из него имена локальных переменных

Вопрос 14 из 30

Как обеспечить security headers на 500?

Хранить набор заголовков в базе и читать его только при статусе 500 Заменить HTTP-заголовки эквивалентными meta-тегами в HTML ошибки Внешний слой заголовков должен оборачивать error middleware Добавлять заголовки только в ветке успешного Response после error middleware Отправить часть заголовков через echo до входа запроса в конвейер

Вопрос 15 из 30

Что опасно в catch, который делает $handler->handle($request) повторно?

RequestHandler обязан откатывать любые выполненные операции перед исключением Второй вызов только восстанавливает тело ответа и не запускает контроллер заново PSR-15 запрещает синтаксически обращаться к handler из блока catch Повторяет непредсказуемо уже начатую операцию Повтор безопасен, если первый вызов завершился исключением до возврата Response

Вопрос 16 из 30

Каков вывод двух оборачивающих middleware?

// A: before; handle(next); after
// B: before; handle(next); after

A-before B-before handler A-after B-after A-before A-after B-before B-after handler A-before B-before handler B-after A-after B-before A-before handler B-after A-after B-before A-before handler A-after B-after

Вопрос 17 из 30

Где должен стоять routing относительно middleware, которому нужны route attributes?

$routed = $router->match($request);
$request = $request
    ->withAttribute('route', $routed->name)
    ->withAttribute('order_id', $routed->params['id'] ?? null);
return $authorization->process($request, $handler);

Routing раньше этого middleware на входном пути Routing можно выполнить после handler: атрибуты будут добавлены к уже обработанному request Порядок слоёв не важен, поскольку route attributes глобальны для процесса Middleware должно само повторно вызвать маршрутизатор на обратном пути Routing достаточно выполнить только при формировании Response

Вопрос 18 из 30

Кэш middleware стоит до auth и кэширует персональный ответ только по URL. Риск?

final class ResponseCacheMiddleware
{
    public function process(Request $request, Handler $handler): Response
    {
        $key = $request->path;
        return $this->cache->remember($key, fn () => $handler->handle($request));
    }
}

Auth автоматически добавит пользователя в ключ уже сохранённой записи Один пользователь может получить ответ другого Кэшированный Response будет выдан лишь после повторной проверки прав получателя Кэш станет бесполезен, потому что авторизация всегда меняет URL запроса Единственный риск — лишнее потребление памяти, содержимое между пользователями не смешается

Вопрос 19 из 30

Почему CORS middleware часто должно охватывать error response?

CORS нужен только HTML CORS исправляет исключения 500 не содержит заголовков вообще Иначе браузер скроет API-ошибку за CORS-ошибкой PHP запрещает Origin в catch

Вопрос 20 из 30

Как проверить порядок без догадок?

Оценить порядок по числу строк до и после вызова handler Сравнить алфавитный порядок имён классов с порядком регистрации Запустить каждый слой отдельно: последовательность общего конвейера из этого следует Добавить разным слоям случайные задержки и отсортировать их по времени Записать маркеры каждого слоя до и после next

Вопрос 21 из 30

Как изолированно тестировать middleware?

$next = new class implements RequestHandlerInterface {
    public int $calls = 0;
    public function handle(ServerRequestInterface $request): ResponseInterface
    {
        $this->calls++;
        return new Response(204);
    }
};
$response = $middleware->process($request, $next);

Подменить весь bootstrap приложения, не задавая поведение следующего handler Использовать реальный внешний сервис, чтобы Response был максимально похож на production Передать fake handler с заданным Response и счётчиком Проверить только конструктор и наличие метода process через Reflection Создать настоящий HTTP-сервер и обращаться к нему для каждого отдельного случая

Вопрос 22 из 30

Что проверять у auth middleware при отсутствии token?

$next = new CountingHandler();
$response = $auth->process($requestWithoutToken, $next);
assert($response->getStatusCode() === 401);
assert($next->calls === 0);

Статус 200 с пустым телом, поскольку отсутствие токена ещё не ошибка Два вызова следующего handler: до и после попытки аутентификации Статус 401 и нулевой вызов следующего handler Статус 403 и один вызов следующего handler с анонимным пользователем Только текст класса ответа, не проверяя статус и продолжение цепочки

Вопрос 23 из 30

Как проверить добавленный user?

Fake handler сохраняет request, тест читает его атрибут Ограничиться статусом ответа, не наблюдая request, полученный следующим слоем Считать пользователя из статического свойства middleware после завершения теста Проверить исходный request: immutable-объект должен получить атрибут после process Прочитать cookie тестового браузера, даже если пользователь передаётся атрибутом request

Вопрос 24 из 30

Зачем проверять исключение из следующего handler?

Проверять только тип исходного request, не результат и не проброс ошибки Преобразовать любое исключение в 200 и проверить, что клиент получил тело Убедиться, что исключение меняет память процесса, а не HTTP-контракт Проверить пропуск или преобразование ошибки по контракту Не задавать исключение: стандарт запрещает handler выбрасывать Throwable

Вопрос 25 из 30

Как найти слой, добавляющий задержку?

Сравнить число параметров конструкторов всех middleware Таймер или span вокруг каждого middleware Увеличить общий timeout и считать проблему решённой, если запрос завершился Измерить только общий TTFB: он не показывает, какой внутренний слой задержал ответ Удалять слои по одному под рабочим трафиком без измерений и контрольной группы

Вопрос 26 из 30

Как обрабатывать X-Forwarded-For?

$remote = $request->getServerParams()['REMOTE_ADDR'] ?? '';
if (in_array($remote, $trustedProxies, true)) {
    $clientIp = parseForwardedFor($request->getHeaderLine('X-Forwarded-For'));
} else {
    $clientIp = $remote;
}

Сохранять строку заголовка как SQL-выражение для последующей фильтрации Считать X-Forwarded-For доказательством личности пользователя после проверки формата Брать крайний левый адрес из любого клиентского заголовка как исходный IP Полностью игнорировать адрес непосредственного прокси при разборе цепочки Доверять цепочке лишь от известных прокси и разбирать по правилу

Вопрос 27 из 30

Где ставить лимит размера тела?

$length = (int) $request->getHeaderLine('Content-Length');
if ($length > 1_000_000) {
    return new JsonResponse(['error' => 'payload_too_large'], 413);
}
return $handler->handle($request);

После отправки письма и выполнения всех предметных побочных эффектов До чтения тела и тяжёлой бизнес-логики В шаблоне Response, когда тело уже полностью прочитано Только в JavaScript: сервер не должен ограничивать входное тело После сохранения разобранных данных в базе

Вопрос 28 из 30

Что должно происходить с метриками при коротком замыкании?

Метрики записывает только конечный handler, а не оборачивающий слой Короткое замыкание нельзя измерить, потому что handler не вызывался При коротком ответе внешний слой должен заменить исходный статус на 200 Внешний слой всё равно пишет статус и длительность Request_id следует удалить, чтобы не связывать ранний отказ с запросом

Вопрос 29 из 30

Почему security middleware нельзя исключать для 404?

Веб-сервер сам добавит одинаковую политику, даже если приложение её не настроило Страницы ошибок не исполняют HTML и поэтому не требуют CSP или nosniff Заголовки безопасности нужны только документам со статусом 200 404 тоже нужен CSP, nosniff и безопасное тело Для 404 достаточно скрыть тело; поведение браузера заголовками не управляется

Вопрос 30 из 30

Как безопасно обновлять pipeline?

Изменить порядок сразу на всём трафике и добавить тесты после выпуска Контрактные тесты порядка, поэтапный выпуск и метрики Отключить журналирование на время изменения порядка слоёв Удалить error middleware, чтобы новая последовательность не скрывала исключения Проверить вручную одну успешную страницу без отрицательных сценариев