La vérité sur les ETags
Un des critères de notation utilisés par l'excellent YSlow pour apprécier la qualité de votre site est l'utilisation des ETags. D'ailleurs, si on consulte les commentaires laissés à ce sujet, on voit l'équipe de Yahoo obligée de se justifier.
Je vais essayer de traduire le consensus sur la question et de vous expliquer en termes simples ce que sont ces ETags.
1. Qu'est ce qu'un ETag, à quoi ça sert?
Un ETag est un code renseigné par le serveur web sur une ressource, et qui est fourni avec l'en tête de la ressource. Cela ressemble à ça: "1ed39b-9a6-45ce4f9c", ou à "-346776727645". Ce code identifie 'de manière unique' la ressource dans le temps et dans son chemin.
C'est donc là pour valider l'unicité d'une ressource ou d'une représentation.
2. Comment sont fabriqués les ETags
Les ETags sont créés par le serveur qui renvoie la ressource. Celui ci utilise différents critères pour créer l'ETag.
Apache utilise par défaut la combinaison de trois éléments pour créer l'ETag : l'inode du répertoire o๠est stocké la ressource, le timestamp unix (une mesure des millisecondes) et la taille du fichier.
IIS utilise une autre façon de générer les ETags. Le format par défaut est Filetimestamp:Changenumber o๠Changenumber est un compteur dans le serveur.
Mon serveur lighttpd une autre encore. C'est toutefois encore une combinaison de node-value (emplacement sur le disque), un timestamp et la taille
3. O๠sont les ETags?
Les ETags sont dans les entêtes des ressources qui sont envoyées par les serveurs http. Lancez votre firebug et regardez une ressource statique sur le site du meilleur opérateur de la planète (qui n'a pas l'iphone toutefois). Et regardez l'entête d'une image. Vous y verrez quelque chose comme "df0fd-1ca1-44fc2b84".
4. Quand sont ils utilisés?
Quand le cache veut utiliser un objet qu'il détient déjà , et qu'il veut l'utiliser comme réponse à la requête d'un client, il doit d'abord vérifier avec la source (ou avec un cache intermédiaire qui a une donnée plus fraà®che) pour voir si sa ressource mise en cache est utilisable (HTTP 1.1 spec 13.3).
Ce cas de figure peut se produire de plusieurs façons:
- vous n'avez pas mis d'informations de cache, comme max-age:36000, si bien que votre cache n'a pas beaucoup d'informations pour juger de la fraicheur de ses ressources. Votre ressource n'est pas fraà®che, le cache doit s'assurer de la fraà®cheur avant de vous la donner. - la date de validité calculée de votre ressource est dépassée. Votre agent doit alors savoir s'il dispose de la représentation la plus fraà®che de la ressource.
Bien sûr, quand je parle de cache, je parle à la fois de votre navigateur et d'un cache intermédiaire (rproxy, proxy, cdn).
5. Est ce que ça marche?
Pour la plupart des sites, cela fonctionne PARFAITEMENT dans la distribution et les réglages de base. En effet pour la plupart des sites, quand un cache a besoin de valider la fraà®cheur d'une ressource en envoyant une ressource de type If-None-Natch, le serveur renvoie une réponse de type 304 : Not Modified.
Le but des ETags est alors rempli : au lieu de faire un aller-retour avec une réponse complète contenant toute la ressource, on a une réponse ne contenant que quelques octets : la transaction est normalement beaucoup plus rapide.
Pour les sites plus gros qui ont besoin de plusieurs serveurs web pour servir leurs fichiers statiques, cela peut devenir plus délicat à utiliser. En effet dans ce cas, il est probable que l'ETag généré pour une ressource (pourtant la même) soit différent suivant le serveur qui la génère, ne serait ce que parce que le inode est différent d'un serveur à l'autre.
Oui, c'est un problème de riche.
6. Comment éviter d'avoir des problèmes à cause de ses ETags
Première solution : n'utiliser aucun cache. Oui, cela va à l'encontre de tous les principes, mais si on ne met pas de directive de cache et qu'on envoie pas d'ETag, on ne risque pas d'avoir le problème évoqué plus tà´t.
Deuxième solution : faites en sorte que vos ETags ne soient jamais nécessaires, avec des ressources qui ont des durées de mise en cache très importante. Pas très malin non plus, et difficile à appliquer à tous les fichiers.
Troisième solution : ne pas utiliser les ETags. Il existe un autre mécanisme de validation (la validation légère) qui repose sur l'entête 'Last-Modified'. Bien que cette validation soit moins précise, elle conviendra dans 99,99% des cas. Bien sûr, il faudra que cette information soit la même sur vos différents serveurs.
Quatrième solution : faites en sorte que vos ETags soient les mêmes sur tous vos serveurs. Pour cela, rabattez vous sur les deux arguments qui peuvent être les mêmes d'un serveur à l'autre : la taille et le timestamp de dernière modification.
7. Les cas limites
Les fichiers gzippés sont différents à chaque fois qu'ils sont regénérés : l'ETag est différent d'une requête à l'autre. Dans ces conditions, lETag n'a servi à rien car on ne peut jamais validé (même si la ressource qui est gzippée n'a pas changé).