J’ai une petite question pour toi concernant la désactivation des Etags :

Au boulot nous avons 2 serveurs en frontend synchronisés via rsync, qui ne synchronise pas les dates de dernière modification. Je me retrouve donc dans le cas ou les Etags générés ne servent pas à grand chose. Nous avons donc ajouté dans le http.conf la directive pour désactiver les Etags. Comment se fait-il que Yslow me donne toujours une note de F et m’affiche un Etag dans les entêtes HTTP ? Préconises-tu de revoir la manière dont sont synchronisés les 2 serveurs et de laisser les Etags activés ? (Nous avons aussi activé Expires pour les images et les CSS et les JS).

Pour le contenu statique, par exemple les images uploadées par les utilisateurs (photos de profil etc…) on voit soit des systèmes de fichier réseau (NFS, autres), soit des serveurs web distincts spécialisés dans la délivrance du contenu statique. Dans ces deux cas, le Etag n’est plus un problème puisqu’on a une seule version du fichier. Est-ce que tu vois d’autres architectures où le Etag pourrait poser problème ?

Donc visiblement, le problème que je soulève a une portée qui reste limitée.

Pour l’instant je n’ai quasiment que vu des rsync, qui savent aussi synchroniser les dates de création/modification. Si tu fais des copies brutes ou si tu n’as pas les droits pour synchroniser les dates, effectivement tu auras des problèmes. Mais dans ce cas le if-modified-since ne fonctionnera pas non plus et tu te retrouves sans mécanisme de revalidation possible.

Il n’y a donc pas de raison de désactiver les ETags et les deux techniques sont complémentaires.

Je vais revoir mes fonctions de mise en cache pour les fichiers html/xml et prendre en compte les ETags.

Donc si ton serveur est configuré pour toujours envoyer une expiration explicite de 24h, à la première revalidation il recevra une nouvelle expiration de 24h et ne fera plus appel au serveur pour 24h supplémentaire.

Pour être plus complet, en HTTP 1,0 les revalidations de cache se font avec les dates de dernière modification. Ca pose quelques problèmes avec les auto-négociations et les mises à jour trop fréquentes donc en HTTP 1,1 on a rajouté les ETags par dessus.
Qu’on les active ou pas, le fait que le navigateur demandera une revalidation et le schéma global de ce qu’il se passe ne change pas. La seule différence c’est que le serveur aura moyen d’être plus exact quand il répond si le document a changé ou pas.

Dans ton exemple :
– ETags désactivés : en fait le document ne sera pas retéléchargés le jour 2, la revalidation du cache se fera à partir de la date de dernière modification et un 304 sera renvoyé de toutes façons (avec la nouvelle expiration de 24h).
– ETags activés : le jour 2 une nouvelle expiration de 24h sera renvoyée en même temps que le code 304, donc on n’aura bien qu’un téléchargement

L’Etag calculé sur la date+taille a l’air en effet une bonne solution supplémentaire en fin d’expiration.
Que se passe-t-il par contre lorsque le fichier est expiré et que le navigateur fait une demande pour savoir si le fichier a été modifié via les ETags? L’expiration est prolongée?

Par contre un (contre) exemple simple ou il faudrait désactiver les ETags :
Un client consulte une page qui finalement ne va pas changer de toute la semaine.
Délai d’expiration de 24h. Le client va consulter cette page plusieurs fois par jour, toutes les heures.

Cas Etags désactivés :
Le jour 1, le client va télécharger le fichier qu’il n’a pas en cache. Toutes les autres consultations du document vont se faire depuis le cache.
Jour 2, le client va retélécharger le document une fois dans la journée.
Ainsi de suite pour les 7 jours, donc cette requête et 7 téléchargements complets.

Cas ETags activés :
Le jour 1, le client va télécharger le fichier qu’il n’a pas en cache. Toutes les autres consultations du document vont se faire depuis le cache.
Le jour 2, le document a expiré et les ETags rentrent en jeu. A chaque nouvelle consultation, une requête de demande de modif va être faite par le client.
Au final, un seul téléchargement du fichier complet, mais 24*6=144 requêtes de demande de modification.

Cet exemple juste pour bien être sûr que j’ai compris le principe, corrige moi si c’est faux.

Quant à gérer le cache soit-même c’est encore une autre question. Sur les scripts, le serveur web n’enverra de toutes façons pas d’ETags. On ne parle donc que des ETags générés automatiquement par le serveur pour des fichiers statiques, ou éventuellement des pages statiques générées.

Un exemple : Imagines que ton système de publication génère et met à jour un fichier RSS statique à chaque nouvel article.
– Tu as une expiration explicite courte (voire pas du tout car l’intérêt est finalement faible dans ce cas précis), de type une heure. Ton client RSS aura besoin des requêtes conditionnelles pour revalider son cache, la plupart le font.
– Si tu laisses faire la simple date de dernière modification tu prends le risques du cas où plusieurs articles arrivent la même seconde, ce qui arrivera certainement à terme, et où un client récupère le fichier entre les deux secondes.
– Reste donc la possibilité de configurer le serveur web pour qu’il génère des ETags avec date+taille afin de dissocier les différentes versions de ce flux RSS.

L’exemple n’est pas si idiot parce que des systèmes à génération régulière de fichiers statiques ça arrive souvent sur les sites à fort traffic. Ce sont des ressources dynamiques (le contenu change régulèrement) donc il n’y a pas d’expiration explicite ou une expiration explicite courte. La présence d’ETag est plus que pertinente.

—

Pour Yahoo! c’est justement ce que je reproche. Ils ne font que soulever le problème des ETags générés à partir des inode dans un cas multi-serveurs. Rien d’autre ne leur pose problème.

Leur comm externe est mal tournée et laisse croire que ce sont les Etags en eux même qui sont négatifs, alors que ce n’est pas du tout le cas.

Je ne peux malheureusement pas trop m’étendre sur Yahoo!, mais je t’assure que leur recommandation est uniquement liée à la question des inode et que si on écarte ce détail il n’y a rien contre les ETags.

L’équipe Yahoo! Performance tient les mêmes propos que toi dans ce billet, à savoir que les ETags doivent être désactivés si il y a plusieurs serveurs HTTP pour gérer le site. Il y a d’ailleurs beaucoup de commentaires à propos de cette directive dans YSlow.

Le fait d’activer les Etag (ou pas), ne change rien à la possibilité de gérer des expirations (infinies pour les ressources statiques, courtes pour certaines ressources dynamiques). Ca ne rentre nullement en conflit avec ta manière de gérer les ressources (qui est la bonne manière de faire d’ailleurs).

Par contre ça jouera sur les quelques ressources pour lesquelles tu ne peux pas mettre une expiration ou pour lesquelles tu dois mettre une expiration courte (genre 24h). Pour ces ressources là, le navigateur tentera une revalidation (soit systématique soit seulement à la fin de l’expiration explicite). Et là l’ETag rentre en jeu.
Encore une fois ça n’entre nullement en conflit avec l’idée de mettre des expirations longues et de gérer le versionement par un changement d’url (et non un changement du contenu). Ca vient en plus.

Maintenant je suis d’accord pour dire que l’utilité est faible. Mon propos dans la conclusion est plus pour prendre le contrepied de la communication de Yahoo!, qui laisse entendre que les Etags sont mauvais par principe, alors que c’est juste certains systèmes de génération par défaut qui posent problèmes, et que si on utilise plusieurs serveurs.

Même si un site est hébergé sur un seul serveur, les Etags ne servent à rien.
Pour les images/scripts et css : on positionne une date de mise en cache dans le futur. On sort ensuite des versions à chaque nouvelle mise en production. Résultat : on économise des connexions inutiles (même si elles sont légères). 10 images, c’est 10 connexions de gagnées!

Pour les fichiers statiques, c’est plus compliqué mais en y réfléchissant, on s’aperçoit que des pages entièrement dynamiques peuvent devenir « statiques » pendant 10 min, 1 heure voire 24 heures.

Je pense que l’on peut vraiment gagner en performances en désactivant les ETags. Et je l’ai mis en pratique sur mon site.