Validateur ETag Faible / Fort | Comparaison selon la RFC 7232
Placez deux valeurs d'en-tête HTTP ETag côte à côte et observez comment la section 2.3 de la RFC 7232 les compare. L'outil détecte le préfixe W/, extrait la valeur entre guillemets et affiche à la fois une correspondance forte et une correspondance faible, pour savoir si un cache, une requête conditionnelle ou une requête de plage aboutirait.
💡 À propos de cet outil
Un ETag est un identifiant qui désigne « cette version précise de cette ressource ». Le serveur l'envoie dans la réponse et le client le réutilise dans des en-têtes comme If-None-Match ou If-Match. La RFC 7232 distingue deux validateurs : le fort ("abc") et le faible (W/"abc").
La règle de comparaison est ce qui prête à confusion. La comparaison forte n'est vraie que si les deux ETags sont forts et que leurs valeurs sont identiques octet par octet. La comparaison faible, elle, ignore le préfixe W/ et se contente de comparer les valeurs. Cette nuance compte : les requêtes Range et If-Range n'acceptent que les validateurs forts. Si votre serveur renvoie un ETag faible, un téléchargement partiel se transforme en réponse complète (200) au lieu d'un 206.
En collant les deux en-têtes ici, la ligne de recommandation vous indique quelles requêtes conditionnelles ce couple satisferait. Tout se déroule dans votre navigateur.
🧐 Questions fréquentes
W/"abc" est-il égal à "abc" ?
En correspondance faible, oui ; en correspondance forte, non. Dès qu'un des deux porte W/, la comparaison forte l'écarte, même si les valeurs sont identiques.
Pourquoi une valeur nue comme abc123 affiche « syntaxe invalide » ?
La RFC 7232 impose des guillemets doubles autour de la valeur. Sans guillemets, abc123 n'est pas un entity-tag valide et ne peut pas être comparé.
La casse et les espaces sont-ils ignorés ?
Non. La valeur opaque est comparée caractère par caractère : "ABC" et "abc" diffèrent, et les espaces internes comptent aussi.
Lequel choisir pour un téléchargement repris ?
Un validateur fort. Range et If-Range rejettent les faibles afin de ne pas assembler des octets issus de deux représentations équivalentes mais non identiques. Visez un couple dont la Correspondance forte affiche OUI.
Gère-t-il les ETags sous forme de hachage ou structurés ?
Oui. Ce qui se trouve entre les guillemets est traité comme opaque : un hachage hexadécimal comme "686897696a7c876b7e" ou une étiquette versionnée comme "v2-2024-01" sont comparés tels quels.
📚 Le saviez-vous
L'en-tête ETag existait déjà dans HTTP/1.1 (RFC 2616), mais l'algorithme de comparaison fort/faible n'a été clairement spécifié qu'avec la RFC 7232 en 2014. Les validateurs faibles répondent à un besoin concret : certaines réponses sont sémantiquement identiques tout en différant octet par octet — une page recompressée avec un autre niveau de gzip, ou un contenu intégrant un horodatage. Les marquer d'un ETag fort casserait la mise en cache via 304, d'où l'introduction de W/ signifiant « équivalent en pratique ». Anecdote : Apache dérivait jadis l'ETag de l'inode, de la taille et de la date du fichier, si bien que le même fichier servi par deux serveurs en répartition de charge produisait des ETags différents — un bug silencieux qui sabotait le cache et a poussé bien des équipes vers des ETags faibles explicites.