Кратко

  • Want-Content-Digest и Want-Repr-Digest передают предпочтения алгоритмов, но не заключают обязательную сделку. Получатель может проигнорировать список, выбрать иной алгоритм или не вернуть поле дайджеста, и это само по себе не является ошибкой HTTP.
  • Для доказательства нужны четыре раздельных состояния: отправленное пожелание, реально полученное поле, охваченный им объект HTTP, а также локальное вычисление и решение.
  • Дайджест выявляет расхождение конкретных байтов. Он не удостоверяет отправителя, не разрешает операцию, не обеспечивает конфиденциальность и не связывает автоматически все метаданные сообщения.

Предпочтение ещё не принято второй стороной

Ползунок с подписью SHA-512 и максимальным значением выглядит как строгая настройка. Однако RFC9530 придаёт ему более скромный смысл: сторона сообщает порядок желательных вариантов. Согласие контрагента из этого сообщения не следует.

Оба поля Want-* используют словарь Structured Fields. Ключ обозначает алгоритм, целое число — относительный приоритет: 1 является наименьшим, 10 наибольшим, 0 означает неприемлемый вариант. Want-Content-Digest относится к содержимому сообщения, Want-Repr-Digest — к выбранному представлению.

Число не служит рейтингом криптографической стойкости или результатом проверки. Даже значение 10 не обязывает другую сторону. Она вправе проигнорировать поле, вернуть алгоритм, которого не было в списке, либо не отправлять Content-Digest и Repr-Digest. RFC9530 прямо указывает: одно только несовпадение с предпочтением не создаёт протокольную ошибку.

Приложение может ввести жёсткое условие — например, прекращать работу при отсутствии допустимого алгоритма. Но такое условие должно быть частью его собственного контракта. В приложении C приведены разные варианты: менее предпочтительный поддерживаемый алгоритм, отсутствие поддерживаемых вариантов, выбранный приложением ответ 4xx или 5xx. Единого обязательного статуса стандарт не устанавливает.

Направление поля также важно. Если сервер помещает Want-* в ответ, он сообщает, какой дайджест хотел бы видеть в будущих запросах. Это не дайджест текущего ответа. Наличие слова Digest в трассировке не доказывает, что проверяемое значение вообще поступило.

Четыре записи вместо одного флага

Первая запись хранит намерение: поле, алгоритмы и их порядок. Вторая описывает наблюдение: пришёл ли Content-Digest или Repr-Digest, какие члены он содержал и находился ли в заголовке либо трейлере. Третья фиксирует охват — содержимое сообщения или выбранное представление. Четвёртая сообщает локальный результат: принятый алгоритм, вычисленные байты, совпадение и действие приложения.

Такой журнал не позволяет превратить «клиент предпочёл SHA-512» в «сервер применил SHA-512». Само присутствие sha-256 ещё не означает, что клиент его пересчитал. А слово «совпало» ничего не говорит без названия поля и объекта.

Принять менее предпочтительный алгоритм иногда разумно. Допустить отсутствие дайджеста для материала с низким риском тоже возможно. Тогда запись должна называть именно это решение: «альтернатива принята политикой» или «отсутствие допустимо». Общий статус успеха скрывает компромисс и создаёт завышенное представление о гарантии.

Содержимое и представление — разные объекты

Термин instance digest из RFC3230 оставлял неоднозначность. RFC9530 разделяет значения. Content-Digest охватывает фактическое содержимое конкретного HTTP-сообщения. Repr-Digest охватывает выбранное представление целиком в смысле семантики HTTP.

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

Методы изменения состояния требуют той же точности. Запрос PATCH может нести документ изменений, а ответ — выбранное представление обновлённого ресурса. Content-Location и Location нельзя безусловно менять местами при определении цели.

Внутреннее поле «payload checksum» стирает необходимые границы. Следует хранить вид дайджеста, значимые метаданные представления, обработку кодирования и стадию, на которой были взяты байты. Иначе два сервиса корректно считают разные материалы и ошибочно считают результаты одной проверкой.

Поддерживаемый алгоритм может быть неприемлемым

В действующем реестре IANA SHA-512 и SHA-256 имеют статус Active. MD5, SHA, варианты UNIX sum, Adler-32 и CRC32C находятся среди Deprecated. RFC9530 оставляет устаревшим алгоритмам некоторые не враждебные сценарии выявления случайной порчи, но запрещает их при наличии противника или в контексте цифровой подписи.

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

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

Журнал должен называть алгоритм, поле, объект и результат. Приложение решает, достаточно ли одного допустимого совпадения, что делать с противоречащими членами и как реагировать, если пришли только неизвестные либо запрещённые варианты. Общий реестр координирует названия, но не принимает риск за оператора.

Поздний трейлер не защищает раннее действие

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

Если система подтвердила изменение, открыла файл или переслала данные до проверки, последующее совпадение не делает прежнее действие условным на целостности. Поздняя проверка полезна для аудита, однако не меняет последовательность. Потерянный трейлер означает отсутствие доказательства.

Совпадение не превращается и в вечную гарантию хранения. Оно относится к байтам в точке проверки. Чтобы утверждать неизменность позже, нужно сохранить весь охваченный объект и пересчитать его. Преобразования и кодирования делают стадию обработки обязательной частью квитанции.

Дайджест не аутентифицирует всё сообщение

RFC9530 намеренно ограничивает свойство. Метод, URI цели, код состояния и иные метаданные не связываются автоматически. Дайджест не устанавливает личность отправителя, не выдаёт разрешение и не скрывает данные.

RFC9421 позволяет включить поле дайджеста и нужные метаданные в HTTP Message Signature. Их необходимо явно выбрать для базы подписи. Соседство подписи и дайджеста в одном сообщении связи не создаёт. Политика ключей, времени и повторов остаётся самостоятельной.

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

Источники и граница утверждений

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