En-tête Repr-Digest
L'HTTPen-tête de requête et de réponse Repr-Digest fournit une fonction 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.
La représentation sélectionnée est le format spécifique d'une ressource choisi par négociation de contenu.
Les détails concernant la représentation peuvent être déterminés à partir des en-têtes de représentation, tels que Content-Language, Content-Type et Content-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.
Un Content-Digest s'applique au contenu d'un message HTTP spécifique et a des valeurs différentes en fonction des Content-Encoding et Content-Range de chaque message.
| Type d'en-tête | En-tête de requête, En-tête de réponse, En-tête de représentation |
|---|---|
| En-tête de requête interdit | Non |
Syntaxe
Repr-Digest: <digest-algorithm>=<digest-value>
// Plusieurs algorithmes de digest
Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>
Repr-Digest est un dictionnaire de champ structuré (RFC 9651: Structured Field Values for HTTP), dont les clés sont <digest-algorithm> et les valeurs <digest-value>.
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-512etsha-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 de l'ensemble des données de la représentation sélectionnée (voir la section 8.1 de la spécification sur la sémantique HTTP (angl.)) utilisant
<digest-algorithm>, encodé en base64 et entouré de deux-points (:, ASCII 0x3A). Cet encodage est appelé une séquence d'octets (angl.) dans la spécification.
Exemples
Dans tous les exemples, les points d'accès sont configurés pour envoyer des en-têtes de digest non sollicités. Les champs Want-Content-Digest et Want-Repr-Digest peuvent éventuellement être utilisés par un expéditeur pour demander un Content-Digest ou un Repr-Digest, ainsi que ses préférences d'algorithme de hachage.
Utiliser un Repr-Digest SHA-256 dans une réponse
Un agent utilisateur demande une ressource :
GET /items/123 HTTP/1.1
Host: example.com
Le serveur répond avec un Repr-Digest de la représentation utilisant l'algorithme SHA-256.
Le digest est calculé sur les octets exacts de la représentation, {"salut": "mdn"} (16 octets, sans inclure explicitement de saut de ligne final) :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
{"salut": "mdn"}
Obtenir des valeurs Content-Digest et Repr-Digest identiques
Un agent utilisateur demande une ressource :
GET /items/123 HTTP/1.1
Host: example.com
Le serveur répond avec un Content-Digest et un Repr-Digest du contenu du message utilisant l'algorithme SHA-256.
Les champs Repr-Digest et Content-Digest ont des valeurs identiques, car ils sont calculés avec le même algorithme sur les mêmes octets, {"salut": "mdn"} (16 octets), et dans ce cas la représentation entière est envoyée dans un seul message :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Content-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
{"salut": "mdn"}
Obtenir des valeurs Content-Digest et Repr-Digest différentes
Un agent utilisateur demande seulement une partie d'une ressource en utilisant une requête de plage :
GET /items/123 HTTP/1.1
Host: example.com
Range: bytes=0-7
Le serveur retourne une réponse 206 Partial Content contenant uniquement les octets demandés, {"salut" (8 octets), comme contenu du message.
Content-Digest couvre uniquement ces octets, tandis que Repr-Digest couvre toujours la représentation entière, {"salut": "mdn"} (16 octets) : les deux valeurs diffèrent donc :
HTTP/1.1 206 Partial Content
Content-Type: application/json
Content-Range: bytes 0-7/16
Content-Digest: sha-256=:pKQv0IAKChzGfyfxu5TNqcnvxIzaG4XICf6NQnB1YhY=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Calculer le digest d'une représentation encodée avec gzip
Dans cette requête, le client utilise l'en-tête Accept-Encoding pour indiquer qu'il accepte la compression gzip :
GET /items/123 HTTP/1.1
Host: example.com
Accept-Encoding: gzip
La réponse du serveur inclut l'en-tête Content-Encoding, indiquant que les octets du message proviennent de la représentation gzip de la ressource.
Le digest est calculé sur les octets encodés avec gzip plutôt que sur le texte original non encodé.
Ici, le corps JSON de 16 octets {"salut": "mdn"} est compressé avec gzip pour former une représentation de 36 octets, et Content-Digest et Repr-Digest sont calculés sur ces 36 octets (présentés ici en hexadécimal pour faciliter la lecture) :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 36
Content-Digest: sha-256=:6Gx6u1ZhhahDLs06Zc6ZEqXxUy8RNjy18CaMucjKOFk=:
Repr-Digest: sha-256=:6Gx6u1ZhhahDLs06Zc6ZEqXxUy8RNjy18CaMucjKOFk=:
1F 8B 08 00 00 00 00 00 02 FF AB 56 CA 48 CD C9 C9 57 B2 52 50 CA 4D C9 53 AA 05 00 35 D8 1D 91 10 00 00 00
Gérer l'absence de contenu avec Repr-Digest
Si la même ressource est demandée avec la méthode HEAD plutôt qu'avec GET, la réponse ne contient aucun contenu :
HEAD /items/123 HTTP/1.1
Host: example.com
La valeur Repr-Digest est la même que précédemment, car elle s'applique toujours à la représentation complète, {"salut": "mdn"}.
Cependant, le serveur n'envoie aucun contenu dans la réponse et peut omettre l'en-tête Content-Digest :
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Plutôt que d'omettre Content-Digest en l'absence de contenu, un serveur peut le calculer explicitement sur une chaîne de caractères vide.
Selon la section 6.3 de la RFC 9530 (angl.), cela permet à un destinataire, notamment lorsque le digest est couvert par une signature de message HTTP, de vérifier qu'aucun contenu n'a été ajouté ou supprimé, plutôt que de vérifier uniquement que l'en-tête a été omis :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Envoyer des digests dans les requêtes avec un agent utilisateur
Dans l'exemple suivant, un agent utilisateur envoie un digest du contenu du message en utilisant SHA-512.
Le digest est calculé sur les octets exacts du corps du message, {"recipient":"Alex","amount":900000000} (39 octets, sans inclure explicitement de saut de ligne final).
Comme la représentation entière est envoyée dans cette requête unique, Content-Digest et Repr-Digest ont la même valeur :
POST /bank_transfer HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 39
Content-Digest: sha-512=:PlrIZYU3M76B30wGsL0h6O79BoxHTdAG+RnMPjOyECTSJCN/KnYdOrSCCWjxV3ckkyvdRmZ52//M3WbehCXcPw==:
Repr-Digest: sha-512=:PlrIZYU3M76B30wGsL0h6O79BoxHTdAG+RnMPjOyECTSJCN/KnYdOrSCCWjxV3ckkyvdRmZ52//M3WbehCXcPw==:
{"recipient":"Alex","amount":900000000}
Spécifications
| Spécification |
|---|
| Digest Fields |
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 utilisant fetch() pour fournir un comportement d'implémentation propre à l'application.
Voir aussi
- Les en-têtes
Content-Digest,Want-Content-Digest,Want-Repr-Digest - L'en-tête
ETag - L'en-tête
Content-Encoding - Signatures numériques pour les API (angl.) guide SDK utilisant des
Content-Digestpour des signatures numériques dans des appels HTTP (developer.ebay.com)