Videz vos caches
Mon devoir de réserve m'interdit de les citer, d'autant qu'il s'agit d'une administration. Il y a quelques semaines (et ce n'était pas la première fois). J'ai eu une demande d'une utilisatrice de la plate forme en ligne d'une administration. Elle a reçu un mail contenant la procédure pour vider ses caches, "pour pouvoir bénéficier des dernières fonctionnalités". La manipulation étant expliquée pour plein de navigateurs, ça faisait trois pages. Je ne sais pas si elle sait ce qu'est le navigateur, alors avoir 3 pages de documentation technique. Hum Au secours.
Je m'étais fait avoir aussi, le CSS n'étant jamais raffraichi sur notre extranet. Ceci dit le développement web n'est pas mon métier premier, une passion que je suis super heureux de pouvoir exercer de temps à autres sur des projets professionnels.
Bon alors pour ne pas avoir à forcer vos boulets d'utilisateurs à vider leur cache, la technique est simple.
Lorsque vous modifiez un fichier CSS, il suffit de le renommer (et aussi de changer le "link"), Idem pour toutes les images qui sont changées, les fichiers flash etc... tout ce qui peut être mis en cache.
Voila, je dis ça comme ça.
Commentaires
Voici une autre astuce qui retire une manipulation.
Il suffit juste de changer le lien vers le fichier CSS :
http://example.com/style.css?a
http://example.com/style.css?b
http://example.com/style.css?c
http://example.com/style.css?d
etc.
Pour le navigateur l’URL est différente, ce qui le force à recharger le fichier. Pour le serveur, il s’agit d’une URL à laquelle on a passé des paramètres mais ceux-ci seront complètement ignorés par le module chargé de servir ces fichiers.
Et ça marche pour toutes les URL qui pointent vers des fichiers à télécharger (images, Flash, PDF etc.) et non vers des programmes (PHP, CGI, Python, Perl etc.).
oui, c'est encore plus simple
Pour moi, c'est un probleme de serveur qui est tente d'etre corrige chez le client au lieu du bon endroit.
Il suffit d'utiliser un server un peu recent qui gere les Entity Tags et Last-Modified Dates. N'importe quel browser tout autant recent saura gerer ca tres bien, ou s'il est trop vieux il gere pas le caching, donc le probleme existe pas ...
Caching in HTTP: http://www.w3.org/Protocols/rfc2616...
Sur le fond, je suis d’accord avec toi Ben, cela devrait se régler au niveau du serveur. Sauf que…
Tout d’abord, le réglage des ETag sur un serveur suppose que tu aies la main dessus ou que tu puisses demander leur réglage, ce qui n’est pas toujours le cas. Et cela d’autant plus que la désactivation des ETags et Last-Modified fait partie des pratiques en matière d’optimisation de site/serveur web. En les supprimant et en se basant sur Expires ou Cache-Control max-age, on supprime du coup toutes les requêtes qui génèrent des réponses 304.
Ensuite, tu n’es pas à l’abri d’un proxy à l’administrateur réseau zélé. Il est possible d’en rencontrer qui sont configurés pour ignorer les ETags et Last-Modified afin de limiter les requêtes et de pousser à l’extrême l’utilisation du cache du proxy.
Bref, la méthode universelle, celle qui va fonctionner à coup sûr sans se demander si la configuration réseau du serveur web jusqu’au client en passant par le proxy est ok, c’est celle décrite dans le billet de Gnieark et dans mon commentaire.
C’est d’ailleurs une technique utilisée dans des CMS très réputés comme Drupal.
Salut vous deux!!!!
Un plaisir de' vous voir ici :D
@Ben, il y a en effet des modules d'apache qui gèrent ça, mais ça m'a paru fastidieux à régler :D
Ce serait l'idéal, pour moi qui code majoritairement en intranet, j'ai la maitrise de la configuration des utilisateurs. Par contre, pour une appli vraiment web. bah zigzagou n'a pas tord.
Je ne savais pas que Drupal le gérait au passage.