ETag

L'en-tête de réponse ETag HTTP est un identifiant pour une version spécifique d'une ressource. Il permet aux caches d'être plus efficaces et d'économiser de la bande passante, du fait que le serveur Web n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas changé. Sinon, si le contenu a changé, les etags sont utiles pour empêcher les mises à jour simultanées d'une ressource de s'écraser mutuellement ("collisions en vol").

Si la ressource à une URL donnée change, une nouvelle valeur Etag doit être générée. Les Etags sont donc similaires aux empreintes digitales et elles peuvent également être utilisées à des fins de suivi par certains serveurs. Une comparaison entre elles permet de déterminer rapidement si deux représentations d'une ressource sont identiques, mais un serveur de suivi peut également leur imposer de persister indéfiniment.

Type d'entête Response header
Forbidden header name non

Syntaxe

ETag: W/"<etag_value>"
ETag: "<etag_value>"

Directives

W/ Facultatif

'W/' (sensible à la casse) indique qu'un validateur faible est utilisé. Les validateurs faibles sont faciles à générer, mais ils sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons, mais ils peuvent être très difficiles à générer efficacement. Les valeurs Etag faibles de deux représentations des mêmes ressources peuvent être sémantiquement équivalentes, mais ne pas être identiques octet par octet.

"<etag_value>"

Balises d'entité représentant d'une façon unique les ressources demandées. Elles sont consituées d'une chaîne de caractères ASCII placés entre apostrophes doubles (comme "675af34563dc-tr34"). La méthode par laquelle les valeurs ETag sont générées n'est pas spécifiée. Souvent, un hachage du contenu, un hachage de l'horodatage de la dernière modification, ou seulement un numéro de révision est utilisé. Par exemple, MDN utilise un hachage de chiffres hexadécimaux du contenu du wiki.

Exemples

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

Évitement des collisions en vol

A l'aide des en-têtes ETag et If-Match (en-US), vous pouvez détecter les collisions d'édition en vol.

Par exemple, lors de l'édition de MDN, le contenu actuel du wiki est haché et placé dans un Etag dans la réponse :

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Lors de la sauvegarde des modifications d'une page wiki ("post" des données), la requête POST contiendra l'en-tête If-Match (en-US) contenant les valeurs ETag par rapport auxquelles vérifier la péremption.

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Si les hachages ne correspondent pas, cela signifie que le document a été modifié entre-temps, et une erreur 412 Precondition Failed est déclenchée.

Mise en cache des ressources inchangées

Un autre cas d'utilisation typique de l'en-tête ETag est de mettre en cache les ressources qui sont inchangées. Si un utilisateur visite à nouveau une URL donnée (qui a un ensemble d'ETag), et qu'elle est périmée, c'est à dire, trop ancienne pour être considérée comme utilisable, le client enverra en même temps la valeur de son ETag dans un champ d'en-tête If-None-Match :

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Le serveur comparera l'ETag du client (envoyé avec If-None-Match) à l'ETag de sa version en cours de la ressource, et si les deux valeurs correspondent (c'est-à-dire que la ressource n'a pas changé), le serveur renverra un statut 304 Not Modified, sans aucun corps, qui indiquera au client que sa version mise en cache de la réponse est toujours bonne à utiliser (actuelle).

Spécifications

Specification
HTTP Semantics
# field.etag

Compatibilité des navigateurs

BCD tables only load in the browser

Voir aussi