Aller au contenu principal

3. Le champ Repr-Digest

Le champ HTTP Repr-Digest peut être utilisé dans les requêtes et les réponses pour communiquer des condensats calculés à l'aide d'un algorithme de hachage appliqué à l'ensemble des données de représentation sélectionnées (voir la section 8.1 de [HTTP]).

Les représentations prennent en compte l'effet de la sémantique HTTP sur les messages. Par exemple, le contenu peut être affecté par des requêtes de plage ou des méthodes, telles que HEAD, tandis que la manière dont le contenu est transféré "sur le fil" dépend d'autres transformations (par exemple, les codages de transfert pour HTTP/1.1 ; voir la section 6.1 de [HTTP/1.1]). Pour aider à illustrer les concepts de représentation HTTP, plusieurs exemples sont fournis à l'annexe A.

Lorsqu'un message n'a pas de données de représentation, il est toujours possible d'affirmer qu'aucune donnée de représentation n'a été envoyée en calculant le condensat sur une chaîne vide (voir la section 6.3).

Repr-Digest est un dictionnaire (voir la section 3.2 de [STRUCTURED-FIELDS]), où chaque :

  • clé transmet l'algorithme de hachage (voir la section 5) utilisé pour calculer le condensat ;

  • valeur est une séquence d'octets qui transmet une version codée de la sortie d'octets produite par le calcul du condensat.

Par exemple :

REMARQUE : retour à la ligne '' selon la RFC 8792

Repr-Digest: \
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

Le type Dictionnaire peut être utilisé pour joindre plusieurs condensats calculés à l'aide de différents algorithmes de hachage afin de prendre en charge une population de points de terminaison ayant des capacités différentes ou évolutives. Une telle approche pourrait soutenir les transitions s'éloignant des algorithmes plus faibles (voir la section 6.6).

REMARQUE : retour à la ligne '' selon la RFC 8792

Repr-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

Un destinataire PEUT ignorer un ou tous les condensats. Le comportement spécifique à l'application ou la politique locale PEUT définir des contraintes supplémentaires sur les pratiques de traitement et de validation des condensats transmis. Les considérations de sécurité couvrent certains des problèmes liés à l'ignorance des condensats (voir la section 6.6) et à la validation de plusieurs condensats (voir la section 6.7).

Un expéditeur PEUT envoyer un condensat sans savoir si le destinataire prend en charge un algorithme de hachage donné. Un expéditeur PEUT envoyer un condensat s'il sait que le destinataire l'ignorera.

Repr-Digest peut être envoyé dans une section de fin. Dans ce cas, Repr-Digest PEUT être fusionné dans la section d'en-tête ; voir la section 6.5.1 de [HTTP].

3.1. Utilisation de Repr-Digest dans les requêtes changeant l'état​

Lorsque la représentation incluse dans une requête changeant l'état ne décrit pas la ressource cible, le condensat de représentation DOIT être calculé sur les données de représentation. C'est le seul choix possible car le condensat de représentation nécessite des métadonnées de représentation complètes (voir la section 3).

Dans les réponses,

  • si la représentation décrit le statut de la requête, Repr-Digest DOIT être calculé sur la représentation incluse (voir l'annexe B.8) ;

  • s'il y a une ressource référencée, Repr-Digest DOIT être calculé sur la représentation sélectionnée de la ressource référencée même si celle-ci est différente de la ressource cible. Cela peut ou non entraîner le calcul de Repr-Digest sur la représentation incluse.

Ce dernier cas est effectué selon la sémantique HTTP de la méthode donnée, par exemple, en utilisant le champ d'en-tête Content-Location (voir la section 8.7 de [HTTP]). En revanche, le champ d'en-tête Location n'affecte pas Repr-Digest car il ne s'agit pas de métadonnées de représentation.

Par exemple, dans les requêtes PATCH, le condensat de représentation sera calculé sur le document de correctif car les métadonnées de représentation font référence au document de correctif et non à la ressource cible (voir la section 2 de [PATCH]). Dans les réponses, au contraire, le condensat de représentation sera calculé sur la représentation sélectionnée de la ressource corrigée.

3.2. Repr-Digest et Content-Location dans les réponses​

Lorsqu'une méthode changeant l'état renvoie le champ d'en-tête Content-Location, la représentation incluse fait référence à la ressource identifiée par sa valeur et Repr-Digest est calculé en conséquence. Un exemple est donné à l'annexe B.7.

Dernière mise à jour le