Кратко

  • RFC 9842 допускает использование HTTP-ответа как внешнего словаря для будущих запросов, если соблюдены правила origin, URL-шаблона, назначения и свежести.
  • Хеш словаря, Available-Dictionary, выбор Content-Encoding, вариант кэша, декодирование и смысл ответа — самостоятельные свидетельства.

Сжатие словарём легко описать слишком широкими словами. Клиент сохранил прежние байты; сервер может на их основе уменьшить будущую передачу. Но клиент не получил будущий ответ заранее. У него есть локальный входной материал, который при конкретных условиях можно предложить для сжатия.

Сервер начинает с Use-As-Dictionary. Он может обозначить ответ как возможный словарь для следующих запросов. Обязательный match ограничен URL Pattern того же origin; match-dest может сузить назначение Fetch, а id и type несут дополнительные ограниченные сведения. Клиент обязан считать id непрозрачной строкой, а сервер не вправе использовать его как гарантию содержимого словаря. Метка не удостоверяет ни байты, ни смысл, ни полномочие.

Далее клиент проверяет собственный контекст. Словарь должен быть свежим либо явно разрешённым для stale-выдачи; у исходящего запроса должны совпасть origin, назначение и шаблон URL. При нескольких совпадениях RFC задаёт порядок выбора. Этот результат означает лишь, что один локальный словарь допустимо объявить для данного запроса. Он не утверждает, что целевой ресурс уже сформирован, что он актуален для бизнеса или что пользователь вправе на нём основывать действие.

Выбрав предложение этой возможности, клиент передаёт ровно один SHA-256 хеш через Available-Dictionary и может указать dcb или dcz в Accept-Encoding. Это сигнал о способности, а не приказ серверу. Сервер может выбрать обычное представление, иное кодирование либо dcb/dcz, если поддерживает предложение и сам выбирает использовать объявленный словарь. Хеш внутри формата связывает сжатый поток с правильным словарём при декодировании. Он не доказывает свежесть смысла ответа, согласие получателя, действительность права или совершённый эффект.

Кэширование имеет собственную границу. Кэшируемый ответ, сжатый словарём, обязан vary по Accept-Encoding и Available-Dictionary, чтобы несовместимый клиент или клиент с другим словарём не получил неподходящий вариант. Но технически правильный вариант HTTP не содержит автоматически все условия доступа, цены, конфигурации или операционного решения. Он может оказаться непригодным, если значимый вне HTTP факт уже изменился.

Правила безопасности не дают короткого пути. Механизм применим только в безопасном контексте, сопоставление сохраняет same-origin, а при неудаче обязательных мер клиент должен отбросить ответ. RFC 9842 предупреждает об утечках размера или времени при совместном сжатии публичных и секретных данных и требует обращаться с хешами словарей как с отслеживаемым состоянием: разделять и очищать их подобно cookies. HTTPS, хеш и общий origin — важные защиты, но не разрешение на действие.

Link relation compression-dictionary всего лишь сообщает, что связанный ресурс может оказаться полезным в будущем. Клиент сам решает, получать ли его; полученный ресурс всё равно требует Use-As-Dictionary и метаданных кэша. Ссылка не доказывает получение, совпадение, использование или результат.

Надёжная запись должна хранить по отдельности URL и хеш словаря, свежесть, проверку origin и шаблона, назначение запроса, объявление клиента, выбор сервера, вариант кэша, декодирование, семантику ответа и самостоятельные решение с эффектом. RFC 9842 уменьшает передачу. Он не сокращает доказательную цепочку до одного заголовка.

Источники