Коди статусу успіху 2xx

Що охоплює родина 2xx

Успіх - не якась одна умова. Браузер, що завантажує сторінку, форма, що надсилає новий запис, фонове завдання, що приймає роботу на потім, і відеоплеєр, що запитує байти з 5 000 000 по 6 000 000, - усе це успішні операції, але їм потрібні різні відповіді. Саме це кодують коди 2xx. RFC 9110 визначає з 200 по 206; кілька інших походять із розширень, як-от WebDAV.

Для повсякденного вебтрафіку переважна більшість успішних відповідей - це прості 200. Решта має значення переважно для клієнтів API, шляхів завантаження й доставки медіа.

Коди 2xx і коли з'являється кожен

• 200 OK. Стандартний успіх. Для GET тіло - це запитаний ресурс; для POST - результат дії. Саме це повертає здорова сторінка.
• 201 Created. Запит створив новий ресурс. Коректний API повертає 201 із заголовком Location, що вказує на щойно створене. Це трапляється в логах API, рідко в браузері.
• 202 Accepted. Запит прийнято до обробки, але вона ще не завершена. Використовується для асинхронної роботи, як-от масовий імпорт чи звіт, що буде згенеровано у фоні. 202 - це обіцянка, а не результат, тож клієнту зазвичай доводиться опитувати URL статусу.
• 203 Non-Authoritative Information. Успіх, але проксі чи проміжний перетворювач змінив відповідь на шляху. Рідкість на сучасних сайтах.
• 204 No Content. Успіх навмисно без тіла. Типово для DELETE, для PUT, що зберіг без потреби щось повертати, чи для ендпоінта автозбереження. Браузер лишається на поточній сторінці.
• 205 Reset Content. Успіх, і клієнт має скинути форму чи вигляд документа, що надіслав запит. На практиці використовується рідко.
• 206 Partial Content. Сервер повертає лише той діапазон байтів, який клієнт запросив заголовком Range. Саме так працює перемотування відео, докачування завантажень і передача великих файлів, тож 206 - нормальний і очікуваний код на медіаендпоінтах.
• 207 Multi-Status і 208 Already Reported походять із WebDAV, де один запит може діяти на багато ресурсів і потребує звітувати результат по кожному окремо. 226 IM Used походить із розширення дельта-кодування і застосовується дуже рідко.

Чому 200 не доводить, що сторінка здорова

Код статусу описує результат HTTP-транзакції, а не правильність того, що повернулося. Брендована сторінка "ми на технічному обслуговуванні" віддається з кодом 200. Так само й сторінка помилки застосунку, коли фреймворк ловить виняток і рендерить чемне вибачення через звичайний шаблон із типовим статусом. Сторінка, що рендериться на клієнті, чий виклик API провалився, повертає 200 для порожньої оболонки навколо відсутнього вмісту, а м'який 404 повертає 200 для повідомлення "сторінку не знайдено", що також плутає пошукові системи.

У кожному з цих випадків перевірка коду статусу звітує успіх, поки ваші відвідувачі бачать зламаний сайт. Виправлення - перевірка вмісту: перевіряйте, що відомий рядок присутній у тілі відповіді, чи що відомий рядок помилки відсутній, на додачу до перевірки коду.

Як перевірити, що URL насправді повертає

1. Запитайте лише заголовки й прочитайте рядок статусу:

   curl -sI https://example.com/ | head -n 1

2. Якщо це 200, отримайте й тіло та підтвердьте, що воно містить те, що має. Пошукайте рядок, який з'являється лише на робочій сторінці, наприклад заголовок чи мітку в футері.
3. Для ендпоінта API перевірте, що код відповідає семантиці: створення має бути 201 із Location, видалення має бути 204, а тривале завдання має бути 202 з URL статусу.
4. Для медіа підтвердьте, що сервер оголошує Accept-Ranges: bytes і відповідає на запит з діапазоном кодом 206. Якщо він відповідає 200 на запит з діапазоном, перемотування буде повільним, бо повторно надсилається весь файл.
5. Повторіть перевірку з іншої мережі. Відповідь, що для вас 200, а деінде помилка, вказує на DNS, CDN чи географічну маршрутизацію, а не на застосунок.

Перевірка тіла, а не лише коду

Перевірка коду статусу покаже зелений сайт, що насправді віддає сторінку помилки, тож поєднуйте її з твердженням про вміст того самого запиту. HostTracker моніторить вебсайти з 2004 року і пропонує 13 типів моніторів, тож за одним URL можна одночасно стежити за кодом статусу, ключовим словом у відповіді й часом відповіді. Пропустіть URL через інструмент HTTP-перевірки, щоб побачити код і заголовки, які він повертає просто зараз, а тоді прочитайте що насправді означає 200 OK і про коди серверних помилок 5xx, які може приховати 200.