ETag

Un ETag (Entity Tag) est un en-tête de réponse HTTP — généralement un hachage ou un tampon de version du corps de la réponse — qui permet à un client de revalider une ressource mise en cache sans la re-télécharger.

Flux de travail :

1. Première requête : le serveur retourne la ressource avec ETag: "abc123".
2. Le client met en cache la réponse avec l’ETag.
3. Requête suivante : le client envoie If-None-Match: "abc123".
4. Le serveur compare l’ETag actuel à celui du client. Si égaux : 304 Not Modified avec un corps vide, le client utilise sa copie en cache. Si différents : 200 OK avec le nouveau corps et le nouvel ETag.

Deux variantes d’ETag :

• ETags forts — changent si les octets changent. Par défaut.
• ETags faibles — préfixés W/, peuvent correspondre à des réponses « sémantiquement équivalentes » (par ex., compressées vs non compressées du même contenu).

L’ETag est l’un des trois mécanismes de validation du cache HTTP (aux côtés de Last-Modified + If-Modified-Since, et Cache-Control max-age). Pour les sites statiques modernes avec des URL d’actifs avec hachage de contenu, l’ETag est rarement nécessaire — mais il reste le cheval de bataille pour les API dynamiques qui souhaitent une mise en cache côté client.

Exemple concret

Un navigateur récupère /api/profile pour la première fois. Le serveur répond : HTTP/1.1 200 OK, ETag: "v42-7a8b9c", corps = 4,2 Ko de JSON. Le navigateur met les deux en cache. Au prochain chargement de page, le navigateur envoie GET /api/profile avec If-None-Match: "v42-7a8b9c". Le serveur calcule l’ETag actuel — toujours "v42-7a8b9c" car rien n’a changé — et répond HTTP/1.1 304 Not Modified avec zéro octet de corps. Le navigateur sert sa copie en cache. Bande passante économisée : 4,2 Ko ; la latence aller-retour est toujours payée. Comparez avec Cache-Control: max-age=300, qui ignore complètement l’aller-retour pendant 5 minutes — et vous voyez pourquoi l’ETag est la deuxième meilleure stratégie de mise en cache.

Quand et pourquoi cela importe

L’ETag importe pour deux flux de travail distincts : la revalidation du cache (économiser de la bande passante quand les réponses sont volumineuses) et le contrôle de concurrence optimiste (prévenir les bugs de mise à jour perdue dans les API REST). L’erreur à éviter dans la mise en cache est de générer un ETag faible à partir d’un horodatage incluant une précision sous-seconde — chaque serveur dans un cluster à charge équilibrée calcule une valeur différente pour la même ressource. Utilisez un hachage de contenu stable (SHA-256 du corps, souvent tronqué à 16 caractères). L’erreur à éviter en concurrence est de ne pas valider If-Match côté serveur. AWS S3, Google Cloud Storage et l’API Stripe appliquent strictement la concurrence basée sur les ETags. Référence : MDN — En-tête HTTP ETag.

Contrôle de concurrence optimiste — le second rôle de l’ETag : l’ETag est aussi le mécanisme standard pour « ne pas écraser mes données si quelqu’un d’autre les a modifiées ». Le client GET la ressource, capture l’ETag, fait des modifications, puis PUT avec If-Match: "abc123". Si la ressource côté serveur a changé depuis (ETag différent), le serveur retourne 412 Precondition Failed et le client sait qu’il doit rafraîchir et refusionner. AWS S3, Google Cloud Storage et la plupart des API REST qui prennent en charge les modifications concurrentes utilisent exactement ce schéma.

Le problème de confidentialité avec les ETags : les serveurs peuvent utiliser des valeurs ETag uniques par utilisateur (essentiellement un cookie émis par le serveur intégré dans les métadonnées du cache) pour suivre les utilisateurs revenant sans définir de vrai cookie — le soi-disant « cookie ETag » ou « supercookie ». Même après qu’un utilisateur a effacé ses cookies, le navigateur envoie toujours l’ETag à la requête suivante, l’identifiant. Les navigateurs partitionnent maintenant les caches HTTP par site de premier niveau (Chrome 86, Firefox 85) pour neutraliser cette attaque. Référence : RFC 9110 §8.8.3 — ETag.