Коды состояния 4xx: что на самом деле значат ошибки клиента

Что означает класс 4xx

RFC 9110 определяет класс 4xx как "Client Error" - ошибку клиента: сервер считает, что ошибся клиент. Сюда входит запрос к тому, чего не существует, запрос без нужных учетных данных, запрос, который сервер отклоняет по политике, и запрос с неверным форматом или слишком большого размера.

При отладке важны три свойства этого класса:

• 4xx - это окончательный ответ именно на этот отправленный запрос. Повторение того же самого запроса обычно даст тот же самый код.
• Тело ответа задумано как объяснение, понятное человеку. Именно поэтому существуют кастомные страницы ошибок, и именно поэтому пустая страница 404 - упущенная возможность.
• Некоторые ответы 4xx по умолчанию кэшируемы. RFC 9111 относит 404, 405, 410 и 414 к кодам, которые кэш может сохранить эвристически, поэтому неверный 404 может пережить баг, который его вызвал.

С какими кодами 4xx вы столкнетесь

• 400 Bad Request: запрос имеет неверный формат, и сервер не может его разобрать. Часто это неверная строка запроса, слишком большой заголовок cookie или сломанный прокси перед приложением.
• 401 Unauthorized: требуется аутентификация, а она либо отсутствует, либо неверна. Сервер обязан отправить заголовок WWW-Authenticate, объясняющий клиенту, как аутентифицироваться.
• 403 Forbidden: сервер понял запрос и отказывается его выполнять. Учетные данные здесь не помогут, потому что отказ - это решение политики, а не сбой аутентификации.
• 404 Not Found: по этому URL не существует текущего представления, либо сервер не признает, что оно есть. Подробно разобрано в руководстве по 404.
• 405 Method Not Allowed: URL существует, но не для этого метода. Сервер обязан перечислить методы, которые он принимает, в заголовке Allow.
• 408 Request Timeout: клиент слишком долго отправлял запрос. Отличается от 504, где задержка происходит за сервером.
• 410 Gone: ресурс существовал и был намеренно удален, и ожидается, что это навсегда.
• 413 Content Too Large и 414 URI Too Long: запрос превысил настроенный лимит, обычно это ограничение на загрузку или на размер заголовков.
• 429 Too Many Requests: достигнут лимит частоты запросов. Именно этот код особенно часто кусает настройки мониторинга.

Когда 4xx на самом деле - ошибка конфигурации сервера

Ярлык "ошибка клиента" - это про роли в протоколе, а не про то, кто виноват. Большинство кодов 4xx, появляющихся на здоровом продакшен-сайте, вызваны чем-то на вашей стороне. Правило переписывания или маршрутизации, переставшее совпадать, превращает рабочие URL в 404 сразу по целому каталогу, и признак этого - 404 сразу на многих URL, а не на одном. Сборка, переставшая выпускать файл с хешем в имени, делает то же самое на уровне файла: каждая страница запрашивает файл, отдающий 404, поэтому страница отрисовывается, но выглядит сломанной.

Основную часть остального объясняют слои безопасности. Правило WAF, фильтр ботов или гео-блокировка могут отдавать 403 реальному трафику, и это легко пропустить, потому что для офисного IP-адреса такие правила обычно срабатывают иначе. Изменение авторизации, из-за которого страница, которая должна быть публичной, начинает отвечать 401, - это 4xx, целиком вызванный сервером. То же касается 400 или 413 от обратного прокси, чей лимит на заголовок или тело меньше, чем у самого приложения, для запроса, который приложение бы приняло.

Как диагностировать 4xx на своем сайте

1. Сначала прочитайте точный код и заголовки. Не судите по странице ошибки - она может быть общей для всех случаев:

   curl -sS -o /dev/null -D - https://example.com/broken-page

   Это покажет строку статуса, а также Allow, WWW-Authenticate, Retry-After и любой заголовок идентификации сервера или CDN.
2. Определите, это один URL или закономерность. Один URL указывает на ссылку или удаленную страницу. Целый префикс пути указывает на маршрутизацию, права доступа или деплой.
3. Проверьте, кто именно ответил. Сравните ответ от граничного узла CDN с ответом от источника. Код 403, существующий только на границе, - это правило WAF или бот-фильтра, а не вашего приложения.
4. Попробуйте другую идентичность клиента. Другой user agent, неаутентифицированная сессия или другая сеть могут превратить код из 403 в 200, что сразу локализует блокировку.
5. Прочитайте строку лога сервера для этого запроса. Логи веб-сервера и приложения фиксируют, какое правило или обработчик выдали код. Этим шагом расследование обычно и заканчивается.
6. Исправьте, затем очистите кэши. Поскольку несколько кодов 4xx кэшируемы, исправленная страница может продолжать отдавать старую ошибку из CDN или кэша браузера, пока запись не будет инвалидирована.

Как найти страницы 4xx, которые вы сами никогда не посещаете

4xx не кладет сервер, поэтому его легко не заметить. Сайт загружается, главная страница в порядке, а один раздел отдает 404 или 403 всем, кроме вас. Запланированная HTTP-проверка сравнивает полученный код с ожидаемым, так что страница, начавшая отвечать 403 вместо 200, поднимает оповещение вместо того, чтобы ждать обращения в поддержку. Откуда идет проверка, тоже важно. HostTracker проверяет из 300+ точек в 158 городах, так что гео-блокировка или региональное правило WAF проявляется как настоящая разница между локациями, а не как загадка. Если же отказавший код - 500, 502 или 503, причина на стороне сервера, и начать стоит с руководства по семейству 5xx.