L'HTTPen-tête de requête etde réponseRepr-Digest fournit unefonction de hachage de la représentation sélectionnée de la ressource cible.Il peut être utilisé pour valider l'intégrité de l'ensemble de la représentation sélectionnée une fois qu'elle a été reçue et reconstituée.

Lareprésentation sélectionnée est le format spécifique d'une ressource choisi parnégociation de contenu.Les détails concernant la représentation peuvent être déterminés à partir desen-têtes de représentation, tels queContent-Language,Content-Type etContent-Encoding.

Le digest de représentation s'applique à l'ensemble de la représentation plutôt qu'à l'encodage ou au découpage en tranches des messages utilisés pour l'envoyer.UnContent-Digest s'applique au contenu d'un message HTTP spécifique et aura des valeurs différentes en fonction desContent-Encoding etContent-Range de chaque message.

Syntaxe

Repr-Digest: <digest-algorithm>=<digest-value>// Plusieurs algorithmes de digestRepr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>

Directives

<digest-algorithm>

L'algorithme utilisé pour créer un digest de la représentation.Seuls deux algorithmes de digest enregistrés sont considérés sûrs :sha-512 etsha-256.Les algorithmes de digest enregistrés non sécurisés (hérités) sont :md5,sha (SHA-1),unixsum,unixcksum,adler (ADLER32) etcrc32c.

<digest-value>

Le digest en octets de la représentation en utilisant<digest-algorithm>.Le choix de l'algorithme de digest détermine également l'encodage à utiliser :sha-512 etsha-256 utilisent l'encodagebase64, tandis que certains algorithmes hérités commeunixsum utilisent un entier décimal.Contrairement aux brouillons antérieurs de la spécification, les octets du digest encodés en base64 standard sont enveloppés entre deux deux-points (:, ASCII 0x3A) dans le cadre de lasyntaxe de dictionnaire^(angl.).

L'utilisation d'algorithmes de digest non sécurisés est fortement déconseillée, car des collisions peuvent être réalistement provoquées, rendant l'utilité du digest faible.Sauf si vous travaillez avec des systèmes hérités (ce qui est improbable, car la plupart s'attendent à l'en-tête obsolèteDigest et ne comprendront pas cette spécification), envisagez d'omettre unRepr-Digest plutôt que d'en inclure un avec un algorithme de digest non sécurisé.

Description

Un en-têteDigest avait été défini dans des spécifications précédentes, mais il s'est avéré problématique car le périmètre auquel le digest s'appliquait n'était pas clair.Plus précisément, il était difficile de distinguer si un digest s'appliquait à l'ensemble de la représentation de la ressource ou au contenu spécifique d'un message HTTP.Ainsi, deux en-têtes séparés ont été définis (Content-Digest etRepr-Digest) pour transmettre respectivement les digests du contenu des messages HTTP et les digests des représentations de ressources.

Exemples

Envoi d'unRepr-Digest dans une requête par un agent utilisateur

Dans l'exemple suivant, un agent utilisateur envoie un digest du contenu du message en utilisant SHA-512.Il envoie à la fois unContent-Digest et unRepr-Digest, qui diffèrent l'un de l'autre à cause duContent-Encoding :

POST /bank_transfer HTTP/1.1Host: example.comContent-Encoding: zstdContent-Digest: sha-512=:ABC…=:Repr-Digest: sha-512=:DEF…=:{ "recipient": "Alex", "amount": 900000000}

Le serveur peut calculer un digest du contenu qu'il a reçu et comparer le résultat avec les en-têtesContent-Digest ouRepr-Digest pour valider l'intégrité du message.Dans des requêtes comme l'exemple ci‑dessus, leRepr-Digest est plus utile au serveur car il est calculé sur la représentation décodée et serait plus cohérent dans différents scénarios.

Réponse HTTP oùRepr-Digest etContent-Digest coïncident

Un serveur HTTP peut envoyer la représentation entière non encodée dans un seul message.Dans ce cas,Repr-Digest etContent-Digest ont des valeurs égales pour les mêmes algorithmes de digest :

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:…Content-Type: text/yamlContent-Encoding: brContent-Length: 38054Content-Range: 0-38053/38054…[message body]

Réponses HTTP oùRepr-Digest etContent-Digest divergent

Un serveur peut compresser le contenu pour l'envoi.Dans ce cas,Content-Digest dépendra de l'en-têteContent-Encoding et aura donc une valeur différente de l'en-têteRepr-Digest dans une réponse :

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809…Content-Type: text/html; charset=utf-8Content-Encoding: br…[message body]

Dans une autre réponse, le serveur utilise une méthode de compression différente, entraînant un nouveauContent-Digest, mais les mêmes digestsRepr-Digest :

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=:…Content-Type: text/html; charset=utf-8Content-Encoding: zstd…[message body]

Requête et réponse HTTP réussies utilisantWant-Repr-Digest,Repr-Digest etContent-Digest

La requêtePUT suivante inclut un en-têteWant-Repr-Digest, indiquant que le serveur doit inclure un en-têteRepr-Digest avec un digestsha-256 si l'opération réussit :

PUT /api/transact HTTP/1.1Want-Repr-Digest: sha-256=8Content-Type: text/json…[message body]

Le serveur répond par une réponse201 Created réussie, incluant les en-têtesRepr-Digest etContent-Digest avec des digests sha-256 de la représentation et du contenu, respectivement :

HTTP/1.1 201 CreatedRepr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:Content-Encoding: brContent-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:…[message body]

Requête et réponse HTTP échouées utilisantRepr-Digest

Dans le message suivant, un agent utilisateur demande une ressource avec un digest sha-256 spécifique :

GET /api/last-transaction HTTP/1.1Accept: text/jsonRepr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:…

Un statut406 Not Acceptable est retourné par le serveur pour indiquer que l'opération a échoué étant donné un digest spécifique pour la ressource.Un en-têteRepr-Digest est inclus avec la valeur du digest SHA-256 qui aboutirait à une réponse réussie si l'agent utilisateur répéta la requête avec cette valeur :

HTTP/1.1 406 Not AcceptableRepr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:…

Spécifications

Compatibilité des navigateurs

Cet en-tête n'a pas d'intégration définie par la spécification au niveau des navigateurs (la section « compatibilité des navigateurs » ne s'applique pas).Les développeur·euse·s peuvent définir et récupérer des en-têtes HTTP en utilisantfetch() pour fournir un comportement d'implémentation propre à l'application.

Voir aussi

• Les en-têtesContent-Digest,Want-Content-Digest,Want-Repr-Digest
• L'en-têteETag
• L'en-têteContent-Encoding
• Signatures numériques pour les API^(angl.) guide SDK utilisant desContent-Digest pour des signatures numériques dans des appels HTTP (developer.ebay.com)