Кратко

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

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

Если бы сервер был уверен во всех полях, он мог бы сразу прислать окончательный ответ. Выигрыш появляется не из ранней достоверности, а из ограниченной неопределённости. Клиент получает шанс сэкономить время и принимает небольшой риск бесполезной работы.

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

HTTP различает промежуточное сообщение и итог

RFC 9110 допускает, что на один запрос придёт ноль, один или несколько информационных ответов класса 1xx, а затем ровно один окончательный ответ не из класса 1xx. Информационный ответ заканчивается вместе с разделом полей и не содержит содержимого или трейлеров. Клиент обязан уметь разбирать 1xx, даже когда не ожидал их; пользовательский агент может неожиданную промежуточную реакцию игнорировать.

Статус 103 занимает это промежуточное место. Он означает, что сервер, вероятно, включит переданные поля в окончательный ответ. Обычно поля повторяются. Однако оставшаяся обработка может показать, что раннее поле ошибочно или больше не нужно.

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

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

Внутренней системе не стоит сливать ранние поля в объект под названием «предварительный окончательный ответ». Такое имя создаёт впечатление почти завершённого решения. На деле есть последовательность прогнозов и отдельный итог с иным статусом.

Отсутствие поля не обещает его отсутствия

Сервер может заранее раскрыть только часть ожидаемых полей. По мере появления новых сведений он вправе отправить несколько 103 и не обязан повторять прежние значения. Клиент может рассматривать их совокупность.

Но отсутствие поля не означает, что оно маловероятно в конце. Early Hints — канал частичных положительных утверждений. Молчание в нём не является отрицательным решением.

Это особенно существенно для правил кэширования, полей безопасности и требований аутентификации. Если их нет в первом сообщении, клиент не получает основания ослабить защиту до окончательного ответа.

Требование заранее перечислить всё выглядело бы надёжнее, но уничтожило бы назначение механизма. Серверу пришлось бы завершить вычисление, которое должно идти параллельно с ранней загрузкой. Неполнота — не случайный дефект, а условие, стоимость которого оценивает получатель.

Правильный эксплуатационный вопрос звучит не как «доверяем ли мы 103». Нужно спросить: «Что мы потеряем, если прогноз неверен?» Отменяемая загрузка небольшого публичного файла не равна бронированию товара, изменению учётной записи, раскрытию секрета или переводу денег.

preload — тип связи, а не команда

Классический пример использует поле Link с отношением preload. Web Linking задаёт общий смысл отношения между целью и контекстом. Поддерживающий клиент может заключить, что раннее получение цели поможет обработать последующее представление.

Это не обязывает всех получателей действовать одинаково. Устройство с дорогим трафиком может отказаться. Браузер может ограничить типы ресурсов и внешние источники. Организация может запретить спекулятивные запросы между источниками. Общим остаётся понимание сигнала, а не объём расходов.

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

Даже успешно загруженный объект не определяет исход основного запроса. Окончательный ответ может оказаться ошибкой, перенаправлением или запросом аутентификации. Ссылка может исчезнуть. Наличие ресурса на устройстве не разрешает автоматически запускать, показывать или использовать его.

Граница проста: 103 может приблизить работу, которая уже независимо разрешена. Сам по себе сигнал не создаёт разрешения.

Первый прогноз может исходить от посредника

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

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

RFC 9110 обычно требует от прокси пересылать ответы 1xx, кроме случая, когда прокси сам запросил появление соответствующего информационного ответа. Это правило сохраняет доставку, но не превращает передатчика в окончательный источник смысла.

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

Телеметрия тоже не должна записывать все подсказки как «слова сервера». Иначе устаревшая оценка edge-узла будет выглядеть как постоянная смена решения приложением.

Ошибка в понятии «промежуточный» разрушает границы сообщений

Раздел безопасности RFC 8297 выделяет конкретный риск HTTP/1.1. Неисправный клиент может принять 103 за окончательный ответ. В постоянном соединении он способен посчитать ответы на следующие запросы частью предыдущего сообщения. Если через соединение проходят запросы к разным источникам, путаница может привести к междоменному раскрытию информации.

Следовательно, «информационный» — не стилистическое смягчение, а структурное состояние. RFC 9112 требует связывать входящее сообщение с первым ожидающим запросом, для которого ещё нет окончательного не-1xx ответа. Несколько сообщений относятся к одному запросу лишь тогда, когда перед итогом идут один или несколько 1xx.

По этой причине RFC 8297 допускает, что сервер не станет отправлять 103 по HTTP/1.1, пока не знает, правильно ли клиент обрабатывает информационные ответы. Для HTTP/2 такой конкретный сбой фрейминга считается менее вероятным: промежуточный ответ идёт блоком полей в определённом потоке, и блок с информационным статусом не может завершить поток. HTTP/3 также разрешает несколько 1xx перед финалом и не допускает в них содержимого или трейлеров.

Современный фрейминг уменьшает одну техническую опасность, но не исключает смысловую. Клиент может безошибочно разобрать HTTP/3 и всё равно счесть прогноз согласием. Целостность транспорта и полномочия действия требуют разных проверок.

Кэш хранит прошлое, а не принимает нынешнее решение

Кэш умеет реагировать рано, потому что помнит прежний ответ. Такая информация может быть очень точной и всё же устареть. Скрипт, который требовался вчера, сегодня может исчезнуть; повторная проверка способна вернуть иной статус или набор зависимостей.

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

Полезные метрики разделяют события: подсказка отправлена, получена, отношение распознано, загрузка началась, поле подтверждено в финале, ресурс действительно использован. Одна «успешность 103» скрывает выброшенные байты, дубли, давление на соединения, издержки приватности и лишнюю нагрузку origin.

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

Малый общий протокол оставляет место местному выбору

Реестр IANA называет код 103 Early Hints и ссылается на RFC 8297. Документ опубликован в 2017 году как экспериментальный протокол IETF. Он отражает согласие сообщества, прошёл открытое рассмотрение и одобрен IESG для публикации, но не относится к Internet Standards Track. Его нельзя выдавать за всеобщую обязанность внедрения.

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

Браузер может обрабатывать только известные отношения. Ограниченное устройство — игнорировать всё. Корпоративный клиент — блокировать внешние цели. Кэш — генерировать подсказки лишь при высокой недавней точности. Единому центру не приходится решать судьбу каждого запроса.

Такой порядок соответствует подходу Lu Heng: минимальная начальная спецификация, локализованное будущее решение и информированное добровольное принятие. Сервер знает ход вычислений, посредник — возраст кэша, клиент — цену сети, ресурсы и credentials. Решение остаётся там, где видны его последствия.

Центральное разрешение для каждого намёка поглотило бы часть выигранного времени. Альтернатива — не отсутствие правил, а заранее подготовленная локальная политика: известные отношения, допустимые источники, предел данных, обращение с credentials и список эффектов, которые никогда не стартуют спекулятивно.

Нужен журнал ставок, а не теневой ответ

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

Затем эффекты классифицируются по цене ошибки. Публичная, ограниченная и отменяемая загрузка может получить бюджет. Изменение состояния, передача ценности, раскрытие информации, согласие или изменение доступа ждут обычного полномочия.

После окончательного ответа проводится сверка: какие поля повторились, исчезли или изменились; какая работа ещё полезна, а какую надо отменить; сколько времени выиграно и ресурсов потеряно. Итоговые поля управляют обработкой, ранняя история объясняет качество прогноза.

Необходимо сохранить и простой выход — игнорирование. Если версия, посредник или сеть становятся рискованными, клиент может перестать действовать по 103 и продолжить правильно обрабатывать окончательные ответы.

Early Hints не претендует на знание будущего. Он делает объявленную неполноту пригодной для ограниченной подготовки. Рано поделиться, локально ограничить потерю и оставить последнее слово завершённому решению — именно эта сдержанность даёт скорость без централизации.

Источники