Информационные коды состояния 1xx

Что такое промежуточный ответ

Любое другое семейство статусов завершает обмен. 200, 404 или 502 - это финальное слово сервера по этому запросу. 1xx устроен иначе: сервер отправляет строку статуса и любые заголовки, затем держит соединение открытым и отправляет второй ответ позже. RFC 9110 требует, чтобы клиенты умели читать один или несколько ответов 1xx перед финальным, и позволяет любому клиенту, не понимающему конкретный код 1xx, его игнорировать.

Промежуточный ответ отбрасывается, как только приходит финальный, поэтому большинство инструментов его вообще не показывают. Панель сети в вашем браузере, лог доступа веб-сервера и проверка мониторинга - все они сообщают финальный статус. Промежуточный ответ сделал свою работу на уровне транспорта и исчез.

Коды 1xx, с которыми вы можете столкнуться

• 100 Continue. Клиент отправил заголовки запроса с Expect: 100-continue и приостановился перед отправкой большого тела. 100 означает "заголовки в порядке, отправляй тело". Если сервер все равно собирается отклонить запрос, он может ответить финальной ошибкой сразу, и клиент не тратит трафик на загрузку полезной нагрузки впустую. Это единственный код 1xx, выполняющий полезную работу на обычных сайтах, обычно за большими загрузками файлов и у API-клиентов вроде curl.
• 101 Switching Protocols. Клиент попросил сменить протокол заголовком Upgrade, и сервер согласился. Это нормальный, успешный итог рукопожатия WebSocket, так что 101 в логе - как правило, хороший знак, а не инцидент.
• 102 Processing. Определен спецификацией WebDAV для долгих запросов, чтобы клиент знал, что сервер не завис. Реализуется редко за пределами WebDAV, и на обычном сайте вы вряд ли с ним встретитесь.
• 103 Early Hints. Сервер отправляет заголовки Link заранее, еще до того как закончил формировать страницу, чтобы браузер мог начать предзагрузку таблиц стилей, шрифтов или скриптов, пока HTML еще формируется. Это функция производительности, а не сигнал об ошибке, и обычно ее включают намеренно на CDN или источнике.

Почему 1xx - это не то, что нужно чинить

1xx сам по себе не несет никакой вины. Не существует такого понятия, как страница, которая "возвращает 100" или "возвращает 101", в том смысле, в каком страница может возвращать 404. Если у вас есть проблема, а 1xx где-то фигурирует в обмене, интересна всегда финальная информация - код состояния, последовавший за ним, либо факт, что финальный ответ вообще не пришел.

Настоящие сбои рядом с 1xx проявляются как зависание или финальная ошибка, а не как сам 1xx:

• Старый прокси или балансировщик нагрузки, не пересылающий промежуточные ответы, из-за чего клиент, ждущий 100 Continue, зависает до срабатывания собственного таймаута.
• Апгрейд WebSocket, никогда не доходящий до 101, потому что прокси перед приложением вырезает заголовки Upgrade и Connection. Соединение тогда откатывается или отказывает вовсе.
• Early hints, выданные со ссылками на ресурсы, которых уже не существует, что тратит запросы впустую, не ломая саму страницу.

Как увидеть ответ 1xx самостоятельно

1. Используйте подробный клиент. Обычный curl -I показывает только заголовки финального ответа, поэтому запросите весь обмен целиком:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Сотрудничающий сервер ответит HTTP/1.1 100 Continue перед отправкой тела, а затем финальным 2xx или 4xx.
2. Для маршрута WebSocket проверьте, доходит ли рукопожатие до HTTP/1.1 101 Switching Protocols. Если нет, сначала посмотрите на слой прокси: заголовки апгрейда действуют только на один переход, и несколько распространенных конфигураций обратного прокси по умолчанию их отбрасывают.
3. Для early hints запросите страницу и поищите блок 103 перед финальным ответом. Не каждый промежуточный узел его пропускает, поэтому отсутствие 103 не всегда означает, что источник его не отправляет.
4. Если большая загрузка зависает вообще без ответа, повторите попытку без заголовка Expect. Если повтор успешен, что-то между вами и источником проглатывает промежуточные ответы.

Мониторинг обмена, который не видно

Поскольку коды 1xx никогда не попадают в лог или на панель, отслеживать нужно финальный ответ и то, сколько времени он занял. Путь загрузки, зависший на промежуточном ответе, снаружи выглядит в точности как медленный или уходящий в таймаут эндпоинт, и внешняя проверка видит это сразу. HostTracker выполняет проверки из 300+ точек в 158 городах, так что запрос, зависающий за конкретным сетевым путем, можно отличить от настоящего сбоя. Прогоните URL через инструмент HTTP-проверки, чтобы увидеть финальный статус и время отклика. Руководства по кодам успеха 2xx и кодам перенаправления 3xx разбирают ответы, которые действительно завершают обмен.