Google Chrome a une gestion du cache pour le moins contestable

Buffer

Google Chrome semble avoir une gestion du cache quelque peu discutable, notamment lorsqu’il s’agit des téléchargements. Une fois un fichier téléchargé, le navigateur ne se connecte plus au serveur afin de savoir s’il a ou non été modifié, mais utilise une version en cache et la télécharge localement comme si de rien n’était.

Je m’en suis rendu compte en travaillant sur un de mes sites. Je venais de remplacer une ressource par une autre, et son nom ayant changé, il me fallait faire une redirection 301 afin de prévenir les navigateurs et les crawlers de son nouvel emplacement.

Je fais donc très classiquement la redirection côté serveur, puis je redémarre.

rewrite ^/ancien/fichier$ /nouveau/fichier permanent;

Il semble, au passage, que Nginx fasse par défaut des redirections 302, et qu’il faille indiquer la directive permanent afin d’obtenir une 301. Dommage qu’ils n’aient pas implémenté un RedirectPermanent comme Apache, mais je m’égare.

Je relance le téléchargement afin de tester ma règle, et Chrome télécharge l’ancien fichier. Je teste avec Webkit, pas de soucis, la règle de réécriture est bien prise en compte. Je relance Chrome, le comportement ne change pas. Un coup d’oeil dans mes logs me confirme qu’aucune requête n’est reçue côté serveur.

Il a fallu que je vide explicitement le cache pour voir enfin une requête arriver à mon serveur. Je ne sais pas trop comment Chromium gère son cache, mais je m’attendais, dans le pire des cas, à un code de retour HTTP 304 en cas de règle incorrecte, mais certainement pas à ça.

Buffer

Publié le 20 février 2010 à 22h30 Publié sous Analyses et Labels cache, browser, google, http, web, bug, chrome

À propos

Je m'appelle Frédéric de Villamil, et quand je ne déploie pas ma mauvaise humeur et ma mauvaise foi sur le Web, je suis un super héros chargé de sauver le monde. Vous pouvez me suivre sur Twitter.

8 commentaires sur Google Chrome a une gestion du cache pour le moins contestable »

Oncle Tom le 20 février 2010 à 22h44
Et si tu ne précises pas de permanent ?

D’un côté, c’est logique : seule l’URL est censée avoir changée, pas forcément le contenu. Menfin c’est marrant qu’il ne fasse pas au moins un HEAD pour voir si la date de modif n’a pas bougée, ou si y’a pas un code redirection.
Frédéric de Villamil le 20 février 2010 à 22h50
Si, justement, ma rewrite rule précise bien permanent. Et je ne comprends vraiment pas le comportement de Chrome qui aurait du à minima faire son HEAD.
Florent V. le 20 février 2010 à 23h30
«Et je ne comprends vraiment pas le comportement de Chrome qui aurait du à minima faire son HEAD.»

Euh, ben ça dépend de ce que tu envoies comme infos côté serveur. Je parle bien sûr des en-têtes HTTP envoyés avec la ressource lorsqu’elle a été récupérée initialement, car la redirection configurée ensuite est un peu hors-sujet ici (tant qu’il n’y a pas de nouvelle requête, le serveur ne peut pas répondre avec une redirection, forcément…).

Pour peu que tu aies un Expires suffisamment loin dans le futur, tu n’as pas de nouvelle requête HTTP. Si par contre tu n’as pas de Expires ou autre indication similaire, et comme seules informations un E-Tag ou Last-Modified, là tu devrais avoir une requête HEAD, effectivement. Enfin si tu n’as aucune information de la sorte, et que Chrome met en cache avec une date d’expiration «par défaut» pour certaines ressources, ça peut être bon à savoir, effectivement.

Des précisions sur les instructions que tu donnes exactement?
Florent V. le 20 février 2010 à 23h32
PS: le bouton de formulaire «Commenter» composé en Comic Sans, c’est en préparation du 1er avril?
mat le 21 février 2010 à 02h30
Je dis comme Florent, c’est parfaitement normal de ne pas re-télécharger le fichier si le Expires/max-age était dans le futur, c’est un peu tout l’interêt; le fait que maintenant ca soit une redirection n’entre pas en jeu. Donc, même si j’adore taper sur Chrome, sans plus d’infos je pense qu’il se comportement parfaitement bien ici.

Fallait venir aux ateliers et conférences performance à Paris-Web :-) Et sinon, http://www.mnot.net/cache_docs/ est ton ami.
Alfred Dagenais le 22 février 2010 à 13h49
Bonjour,

Merci beaucoup pour cet article, car il pourra surement aider à mieux comprendre certains problèmes dont mes clients me font part. Sinon, je crois que l’idéal serait d’avoir un lien pour télécharger un fichier du style : www.mondomaine.com/monfichier.zip?12546789

Le 12546789 représenterait soit la version du logiciel ou tout simplement le temps (time() de PHP). Ce qui forcerait le fichier à être retélécharger à chaque clique, car le temps changerait à chaque seconde, évidant :P

Bonne journée à tous!
Maxime le 23 février 2010 à 14h34
En fait, c’est le comportement attendu. Si tu as servi avec ta ressource des headers donnant une date d’expiration dans le futur, c’est normal qu’il ne fasse même pas de HEAD.

C’est justement en faire ou redemander la ressource arbitrairement sans respecter les consignes de cache qui n’est pas normal. Normalement, sur une page, lors d’un clic, FF respecte ça. Lors d’un F5 il va envoyer les HEAD pour voir s’il y aurait du 304 ou pas (et donc retélécharger la ressource). Lors d’un Ctrl+F5 il envoie des GET pour tout reprendre.
ahmed agnaou le 21 avril 2010 à 01h27
Ils ont bousilles ma vie,je ne dors plus à cause de ces irresponssables de google depuis 10 jours. je passe toutes mes nuits pour trouver une solution comment effacer le cache de google chrome. A partir de ce jour,je téléchargerai plus jamais les produits google.