Comment faire pour recharger une image à partir du serveur. [Résolu]

Bonjour,

J'ai une page servie avec :

cache-Control: no-store, no-cache, must-revalidate

1/ Maintenant, une action de l'utilisateur sur des sélecteurs permet de changer les images affichées sur cette page.
2/ C'est un JavaScript qui se charge de la modification des images en initialisant l'attribut src de balises img avec son chemin d'accès absolu sur le serveur.
3/ Les images changent assez fréquemment sur le serveur tout en utilisant toujours les mêmes noms de fichier.

Manifestement, mon navigateur part toujours chercher l'image en cache malgré la directive de cache-control.

Que faire ?
Modifié par aCOSwt (06 Mar 2009 - 16:09)

Bonjour,

Une solution, qui n'est pas forcément la meilleure, serait de passer en paramètre de l'image un nombre aléatoire ou la date actuelle. Au final, le code généré par Javascript serait comme celui-ci :

<img src="image.png?549394596" ... />

ou avec la date et heure

<img src="image.png?20090303193045588" ... />

Tu peux trouver quelques exemples similaires sur le Web.
Modifié par Tony Monast (04 Mar 2009 - 03:22)

Salut Tony et merci pour ta réponse,

Je crains bien qu'en finale, à défaut de trouver un moyen de mieux piloter les caches (parce qu'il y a aussi certainement le cache des ISPs à prendre en compte), je doive effectivement me rabattre sur un bricolage du genre de celui que tu suggères.

Hello,

Et avec un "Cache-Control: public;max-age=60" ou avec une entête Expires ça pourrait peut être marcher car il n'y a pas de raison que ça ne marche pas

AspiGeek a écrit :
car il n'y a pas de raison que ça ne marche pas

Salut AspiGeek,

Si en fait... il y en a une bonne. C'est que la directive de cache vaille pour la page mais pas pour... ce qui a dedans...
i.e. : .js externes entre balises script, sources de balises images et autres pdf...

Maintenant, avec ton expires, tu ouvres certainement une piste.
Une solution pourrait évidemment être que je trouve un moyen simple pour servir mes .jpg avec une entête expires...
A première vue je crains un peu une usine à gaz impliquant mon .htaccess et du mod_rewrite... mais... pourquoi pas après tout...
Je vais regarder.

Merci pour ton intervention.

Ah ok, je n'avais pas tout compris
Dans ton cas, il faudrait modifier l'Etag de la ressource en question c'est certainement la meilleure solution si ton site est hébergé que sur un seul serveur.

Après sur le modus operandi, peu pas trop t'aider malheureusement mais sur le principe il faudrait modifier l'Etag de la ressource servie comme ça a chaque nouvelle requête il trouvera un etag différent sur le serveur et forcera un rechargement de la ressource.

Il est aussi possible de désactiver les Etags pour voir si ce n'est pas ça qui bloque ton entête cache-controle à ce moment là c'est le last-modified qui est pris en compte.

Bon j'arrête là car je commence à m'embrouiller avec les etags, last modified, cache-control, expires etc

a écrit :
Manifestement, mon navigateur part toujours chercher l'image en cache malgré la directive de cache-control.

Normal si la directive concerne ta page HTML, et pas ton image. Les en-têtes HTTP sont propres à chaque réponse HTTP, et donc à chaque fichier.

(En passant: Cache-Control: no-store, c'est le mal pour toute page où l'utilisateur est amené à saisir des informations.)

a écrit :
Normal si la directive concerne ta page HTML, et pas ton image. Les en-têtes HTTP sont propres à chaque réponse HTTP, et donc à chaque fichier.

C'était bien ce qu'il me semblait

Florent V. a écrit :
(En passant: Cache-Control: no-store, c'est le mal pour toute page où l'utilisateur est amené à saisir des informations.)

Bonjour Florent.
Je me suis précipité relire la reco W3C sur le sujet (qui correspond exactement à mon besoin) et je t'avouerai ne pas avoir vu le mal en question.
Je sais qu'IE6 était réputé pour avoir des problèmes avec les pdf dans ce cas mais, cela ne correspond pas à mon cas.
Alors, si tu pouvais détailler (un peu), je t'en serais reconnaissant, je suis certainement passé à coté de quelque chose.

@AspiGeek : Mes images sont bien livrées avec un header comportant les infos etag et last-modified. Si une image change coté serveur, ces infos sont bien mises à jour. Néanmoins, le navigateur (ou l'ISP ?) récupère de toutes façon la page en cache.

Pour l'heure, en attendant mieux et probablement via une usine à gaz sur l'expires, j'ai intégré le bricolage (efficace) suggéré par Tony.
Modifié par aCOSwt (06 Mar 2009 - 12:18)

a écrit :
Mes images sont bien livrées avec un header comportant les infos etag et last-modified. Si une image change coté serveur, ces infos sont bien mises à jour.

Justement c'est l'inverse qu'il faut faire, c'est à dire modifier l'etag dans la réponse http servi à ton navigateur car celui du serveur reste fixe, comme ça tu es sûr qu'à chaque consultation la ressource sera téléchargée.

Le problème c'est qu'on est dans apache là et que je ne peux t'en dire plus mais je sais que beaucoup supprime l'etag pour optimiser leur site (c'est aussi une directive Yahoo un peu abusive car elle ne s'applique que dans un seul cas.)

Voilou, quelque soit ta solution je te souhaite bon courage

aCOSwt a écrit :
Alors, si tu pouvais détailler (un peu), je t'en serais reconnaissant, je suis certainement passé à coté de quelque chose.

Si une page est en Cache-Control: no-store, le navigateur ne conserve pas les informations saisies lors d'un rafraichissement de la page ou si on revient en arrière.

Petite anecdote vécue: j'écris un commentaire assez long sur un blog (un quart d'heure de recherches et de rédaction). Je valide, en ayant oublié de saisir mon nom et courriel (les champs de saisie étaient à droite, ce qui n'est pas conventionnel, donc j'avais zappé...). Bien entendu le système de blog m'avertit d'un problème, ici sur une page d'erreur dédiée. Je veux donc revenir en arrière, et là Firefox, au lieu d'afficher instantanément la page précédente dans l'état où je l'avais laissé, se met à retélécharger la page et les divers éléments. Paf, message perdu. Je vérifie les en-têtes HTTP: Cache-Control: no-store, etc.

On a eu le problème sur le forum d'Alsa en travaillant sur la V3 (le forum a été très peu modifié mais il y a eu des changements côté config du serveur). Faire un simple rechargement de la page vidait tous les champs de formulaire remplis par l'utilisateur. Revenir en arrière depuis la page de réponse, puis revenir à la page de réponse (via les boutons Précédent et Suivant du navigateur): même chose. J'ai perdu de nombreux messages (deux-trois heures de boulot en cumulant une vingtaine d'incidents de la sorte) lors de la phase de test (privée) de la V3.

Le fait est que la plupart des sites n'utilisent pas Cache-Control: no-store, et que donc certains comportements considérés comme «normaux» (retenir les informations dans les champs de formulaire lors d'un rafraichissement de la page ou de la navigation dans l'historique) sont perturbés.

Cache-Control: no-store, c'est le mal.

Merci Florent V pour le détail.
Je comprends ta haine mais... relativement au cas particulier de ma page en question, cela ne posera pas ce type de problème.

<joking>C'est donc UN mal</joking>

Merci Aspigeek pour ton aide et tes encouragements.