Кратко

  • RFC 9659 требует, чтобы HTTP-zstd decoder поддерживал Window_Size до 8 MB включительно, а encoder не создавал frame с большим требованием.
  • Метрика compression ratio, правильный header и HTTP 200 не показывают, какие bytes выбрал cache, сколько памяти было у клиента и завершился ли decode.
  • Доказательство соединяет версию encoder и frame header с преобразованиями, variant key, effective limit, decode result и application acceptance.

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

RFC 9659 вводит для HTTP content coding zstd симметричную границу. Decoder ОБЯЗАН поддерживать Window_Size до 8 MB включительно, а encoder НЕ ДОЛЖЕН создавать frame, требующий больше. Производитель не перекладывает произвольную память на получателя; получатель, заявляющий coding, не опускает общую линию ниже 8 MB.

Window — свойство frame, а не графика эффективности

RFC 8878 определяет формат Zstandard. Window ограничивает расстояние back-reference к уже декодированным данным и тем самым влияет на историю, которую хранит decoder. Формат допускает значения от 1 KB примерно до 3,75 TB. Большое окно может улучшить compression ratio ценой памяти у получателя.

RFC 8878 уже рекомендовал для HTTP предел 8 MB, но не делал его обязательным. Encoder мог считать большее окно допустимой оптимизацией, а browser — отклонить его ради защиты ресурсов. RFC 9659 превращает рекомендацию в проверяемое правило. Канонический текст и XML source фиксируют одну и ту же пару требований.

Страница RFC Editor показывает, что это Informational RFC, обновляющий RFC 8878. Поиск errata и история Datatracker дают политике точную внешнюю версию: недостаточно помнить число, нужно знать состояние публичного текста.

Negotiation не равен decode

RFC 9110 задаёт семантику content codings. Accept-Encoding: zstd участвует в выборе representation; Content-Encoding: zstd называет применённое преобразование. Ни один header не сообщает окно Zstandard. Он не показывает binary encoder, повторное сжатие intermediary, доступную процессу память или принятие содержимого приложением.

Поэтому счётчик zstd responses может быть истинным и бесполезным как доказательство. Server считает выбор до распаковки. Edge считает 200 до действий клиента. Маленький canary не достигает границы. Один user agent работает в разных версиях и средах. Символический статус «включено» нельзя переносить на runtime outcome.

RFC 7694 показывает аналогичную границу для request content: объявление допустимых codings не доказывает корректность конкретного body и его обработку. Offer, selection, bytes и result должны быть разными записями в обоих направлениях.

Cache разделяет одну URL на несколько реальностей

RFC 9111 включает cache в семантику доставки. Старый zstd object может оставаться fresh после исправления encoder. Edges могут хранить разные generations. Purge может не покрыть один key. Fallback может оказаться под недостаточно отличимой variant identity.

Проверяемая единица — не URL и не текущая настройка origin, а конкретный byte stream. Нужны object hash, variant key, generation, age, invalidation, transformations, frame-header parse и client class. Правильный новый object и неправильный старый object существуют одновременно; агрегат не должен стирать их различие.

Реестр IANA HTTP Parameters теперь описывает zstd как Zstandard stream с Window_Size не более 8 MB. Реестр защищает общее значение token, но не проверяет cache. Запись создаёт оправданное ожидание; frame подтверждает исполнение.

Возможность библиотеки и effective budget различаются

Library может поддерживать 8 MB, а вызывающий process — применять меньший limit из-за concurrency, container policy или memory pressure. Allocation может не состояться. Decode может завершиться, но parser отклонит содержание. Слово «поддерживает» требует версии, конфигурации, момента и результата.

Получатель должен сохранять user agent или library version, effective limit, observed window, decode result и error class. Oversized window, truncation, corruption, unknown coding, allocation failure, dictionary mismatch и application rejection нельзя складывать в одну причину.

RFC 9659 прямо говорит, что decoder может получить oversized nonconforming frame и закончить ошибкой. Обязанность поддерживать до 8 MB не означает бесконечную память. Правильный отказ вне контракта отличается от неудачи внутри него.

dcz не расширяет zstd

RFC 9842 определяет Compression Dictionary Transport и coding dcz. Его правило окна может зависеть от dictionary и достигать 128 MB. Это другой coding и другой контракт. Он не отменяет предел 8 MB для обычного zstd по RFC 9659.

Общая compression library может скрыть различие за единым параметром window. Evidence обязана сохранить coding token, dictionary identity и frame context. Повторное использование кода не превращает два внешних обещания в одно.

Соединить экономию с доставкой

У producer сохраняются encoder binary, version, effective configuration, coding, object hash и frame header. Каждый intermediary записывает pass-through, decode, recompress или replace. Cache хранит key, generation, freshness и invalidation. Recipient хранит version, budget, window, result и error. Application фиксирует acceptance, а не выводит его из transport completion.

Sampling следует направлять на границы: крупные objects, старые generations, разные edges, constrained clients, rollback, fallback и key changes. Frame выше 8 MB, hash без transformation provenance, старый object после смены cap и разрыв между negotiation и application completion требуют расследования.

Minimum Initial Specification Хэна Лу предлагает малую общую линию — 8 MB и явную семантику ошибки — с локальной свободой внутри неё. Reality Layers не позволяют метке zstd присвоить власть decode success. Running-Code Primacy возвращает последнее слово реально поданному frame и реально исполнившему его получателю.

RFC 9659 делает контракт ясным. Руководство должно сделать столь же ясной связь между экономией и фактом успешной доставки.

Источники