Коди стану 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: за цією адресою немає жодного актуального представлення, або сервер не визнає, що воно є. Детально розглянуто в посібнику про 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 одразу на багатьох адресах, а не на одній. Збірка, яка перестає генерувати захешований файл, робить те саме на рівні файлу: кожна сторінка запитує файл, що повертає 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. Визначте, це одна адреса чи закономірність. Одна адреса вказує на посилання чи видалену сторінку. Цілий префікс шляху вказує на маршрутизацію, права доступу або деплой.
3. Перевірте, хто відповів. Порівняйте відповідь від краю CDN із відповіддю від origin-сервера. 403, що існує лише на краю CDN, - це правило 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.