HTTP-заголовок Content-Digest запроса и ответа содержит дайджест, вычисленный с помощью алгоритма хеширования, применённого к содержимому сообщения. Получатель может использовать Content-Digest для проверки целостности содержимого HTTP-сообщения.

Поле Want-Content-Digest позволяет отправителю запросить Content-Digest, а также указать предпочтительные алгоритмы хеширования. Значение дайджеста содержимого зависит от Content-Encoding и Content-Range, но не от Transfer-Encoding.

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

Синтаксис

Content-Digest: <digest-algorithm>=<digest-value>

// Multiple digest algorithms
Content-Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>, …

Директивы

<digest-algorithm>

Алгоритм, используемый для создания дайджеста содержимого сообщения. Безопасными считаются только два зарегистрированных алгоритма дайджестов: sha-512 и sha-256. К небезопасным (устаревшим) зарегистрированным алгоритмам дайджестов относятся: md5, sha (SHA-1), unixsum, unixcksum, adler (ADLER32) и crc32c.

<digest-value>

Дайджест содержимого сообщения в байтах, вычисленный с использованием <digest-algorithm>. Выбор алгоритма дайджеста также определяет используемую кодировку: sha-512 и sha-256 используют кодировку base64, тогда как некоторые устаревшие алгоритмы дайджестов, например unixsum, используют десятичное целое число. В отличие от предыдущих редакций спецификации, стандартные байты дайджеста в кодировке base64 заключаются в двоеточия (:, ASCII 0x3A) в соответствии с синтаксисом словаря.

Описание

В предыдущих спецификациях был определён заголовок Digest, однако он оказался проблематичным, поскольку область применения дайджеста была определена неясно. В частности, было трудно понять, относится ли дайджест ко всему представлению ресурса или к содержимому конкретного HTTP-сообщения. Поэтому были определены два отдельных заголовка (Content-Digest и Repr-Digest) для передачи дайджестов содержимого HTTP-сообщений и дайджестов представлений ресурсов соответственно.

Примеры

Запрос пользовательского агента на дайджест содержимого SHA-256

В следующем примере пользовательский агент запрашивает дайджест содержимого сообщения, отдавая предпочтение SHA-256, а затем SHA-1 с более низким приоритетом:

GET /items/123 HTTP/1.1
Host: example.com
Want-Content-Digest: sha-256=10, sha=3

Сервер отвечает Content-Digest содержимого сообщения, вычисленным с помощью алгоритма SHA-256:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "world"}

Совпадающие значения Content-Digest и Repr-Digest

Пользовательский агент запрашивает ресурс без поля Want-Content-Digest:

GET /items/123 HTTP/1.1
Host: example.com

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

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 19
Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "world"}

Различающиеся значения Content-Digest и Repr-Digest

Если повторить запрос из предыдущего примера, но использовать метод HEAD вместо GET, поля Repr-Digest и Content-Digest будут различаться:

GET /items/123 HTTP/1.1
Host: example.com

Значение Repr-Digest останется прежним, но тела сообщения нет, поэтому сервер отправит другое значение Content-Digest:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

Отправка пользовательским агентом Content-Digest в запросах

В следующем примере пользовательский агент отправляет дайджест содержимого сообщения, используя SHA-512. Он отправляет и Content-Digest, и Repr-Digest, значения которых различаются из-за Content-Encoding:

POST /bank_transfer HTTP/1.1
Host: example.com
Content-Encoding: zstd
Content-Digest: sha-512=:ABC…=:
Repr-Digest: sha-512=:DEF…=:

{
 "recipient": "Alex",
 "amount": 900000000
}

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

Спецификации

Совместимость с браузерами

Для этого заголовка не определена интеграция со стороны браузеров («совместимость с браузерами» неприменима). Разработчики могут задавать и получать HTTP-заголовки с помощью fetch(), чтобы реализовать поведение, специфичное для приложения.

См. также

• Заголовок Want-Content-Digest для запроса дайджеста содержимого
• Заголовки дайджеста представления Repr-Digest и Want-Repr-Digest
• ETag
• В руководстве SDK «Цифровые подписи для API» описывается использование Content-Digest для цифровых подписей в HTTP-вызовах (developer.ebay.com)