Коды состояния успеха 2xx

Что охватывает семейство 2xx

Успех - не одно-единственное состояние. Браузер, получающий страницу, форма, отправляющая новую запись POST, фоновая задача, принимающая работу на потом, и видеоплеер, запрашивающий байты с 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, получите и тело тоже и убедитесь, что оно содержит то, что нужно. Ищите grep-ом строку, появляющуюся только на рабочей странице, например заголовок или маркер в подвале.
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.