Кратко

  • 103 Early Hints — информационный ответ, разрешающий подготовку, пока сервер формирует окончательный ответ.
  • Ранние поля могут измениться, а итогом может быть успех, перенаправление, ошибка клиента или ошибка сервера.
  • Ссылка preload описывает отношение к цели, но не доказывает успешную загрузку или наличие полномочий.
  • Мониторинг должен сохранять всю последовательность ответов и результаты опережающих запросов до вывода о доступности.

Представим панель доставки, которая запоминает первый увиденный статус. Пограничный узел отправляет 103 Early Hints с двумя ссылками preload, и индикатор становится зелёным. Затем тот же запрос завершается 503 Service Unavailable, а один из ранних запросов ресурсов не выполняется. Сам ответ 103 был корректным сигналом и мог помочь сократить задержку. Вывод о готовности был ложным.

RFC 8297 определяет Early Hints как способ использовать время, пока сервер готовит финальный ответ. Клиент может открыть соединение или запросить вероятную таблицу стилей. Оптимизация ценна именно потому, что начинается до того, как результат известен.

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

Поля 103 не заменяют поля финального ответа. За пределами оптимизации производительности их оценка не должна менять обработку окончательного результата. Preload готовит работу, но не выдаёт доступ, не выбирает представление и не превращает незавершённое решение в успех.

RFC 9110 задаёт общую модель. Один запрос может получить ноль или несколько промежуточных ответов класса 1xx, а затем ровно один окончательный ответ другого класса. 1xx сообщает о ходе обработки, 2xx — об успехе, 3xx — о перенаправлении, 4xx — об ошибочном условии со стороны клиента, 5xx — о неспособности сервера выполнить запрос. Приравнивание 103 к успеху преждевременно сжимает упорядоченную цепочку в один флаг.

Даже финальный ответ не всегда полностью описывает результат для пользователя. Документ 200 может ссылаться на ресурс, который позже не загрузится, опоздает, не пройдёт проверку целостности или будет заблокирован политикой. Анонимный пробник может увидеть не то, что получит авторизованный сеанс. Цепочку HTTP необходимо связать с результатом, который оператор действительно стремится гарантировать.

RFC 8288 определяет веб-ссылки как типизированные отношения между контекстным и целевым ресурсами. Поле Link с отношением preload называет цель и способ подготовки. Оно не удостоверяет DNS, соединение, TLS, авторизацию, пригодность к кэшированию, целостность объекта или успешную передачу.

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

Опережающие запросы расходуют ресурсы. Лишний preload занимает соединение, полосу, энергию устройства и место в кэше. RFC 8297 ограничивает раннюю обработку, потому что оптимизация может затронуть безопасность и конфиденциальность. Выводом должно быть не отключение Early Hints, а прозрачный учёт области, стоимости и результата.

Квитанция цепочки HTTP должна хранить метод и цель запроса, протокол, соединение и точку наблюдения; все информационные ответы по порядку; окончательный статус и поля; а при возможности — хеш финального представления. Для каждой цели опережающего запроса нужны тип отношения, вызвавший её 103, режим учётных данных, результат кэша, конечный статус, целостность и длительность. Идентификатор посредника, контекст авторизации и время дополняют запись без сохранения секретов.

Тогда панель различает «103 замечен», «preload начат», «финальный 200 получен», «представление проверено» и «транзакция приложения завершена». Их можно показать вместе, но первое событие не должно автоматически создавать остальные.

Разделение улучшает диагностику. Если 103 приходит быстрее, а окончательный ответ медленнее, стоит исследовать позднюю работу приложения. Если ресурс не грузится только через один edge, возможна проблема маршрута, кэша или развёртывания. Если финальный набор ссылок изменился, вероятно позднее решение о контенте, маршрутизации или авторизации. Владельцы у этих проблем разные.

Если не приписывать механизму лишних свойств, Early Hints даёт полезное свидетельство: наблюдаемая цепочка HTTP достигла этапа, когда можно было сообщить предварительные отношения. Оно помогает увидеть напрасные опережающие запросы и различия между узлами. Но обещать ещё не пришедший окончательный ответ оно не может.

Источники

RFC 8297 — An HTTP Status Code for Indicating Hints; RFC 9110 — HTTP Semantics; RFC 8288 — Web Linking.