J'ai un souci récurrent, lorsque je modifie un script déclaré externe
(<script src="machintruc.js">), ses effets DHTML ne sont visibles
qu'après réactualisation de la page Web appelante. C'est la conséquence
indésirable et secondaire du caching côté client.
Or, cette réactualisation ne se fait, je crois, que de 2 façons : soit
volontairement par l'internaute (bouton "actualiser" ou "recharger"),
soit après réouverture du navigateur. Sans compter le cache du proxy FAI
qui, lui, n'est pas gérable.
J'ai bien envisagé la solution de passer le script par PHP (<script
src="machintruc.php">) en déclarant les headers adéquat pour inhiber les
caches, mais je perd définitivement l'avantage du caching dans ce cas.
Je cherche donc une solution intermédiaire.
Avez-vous quelque idée, ou pratique déjà utilisée en production ?
Ça ne m'était pas venu de suite à l'esprit, mais la solution la plus simple est effectivement de rajouter un paramètre en GET dans l'appel au fichier de script :
<script src="myscript.js?version=2.0"></script>
Je ne comprends rien à ton truc ! Je croyais que la page était bloquée dans le cache pendant 12 heures ?
Moi, ce que j'avais compris, c'était que la page HTML était bien rechargée, mais pas le script myscript.js.
Je ne comprends pas pourquoi. Si la page est rechargée, le navigateur devrait à minima s'assurer que les éléments y inclus n'ont pas changé depuis la dernière visite, non ?
Sinon comment tester ses bricolages JS ?
Encore que parfois j'ai des problèmes de rafraichissement d'images issues de CSS (tt du moins en local).
Que va-ce changer au problème d'avoir une légère variation de son code ?
L'URL du script étant différente, ni le navigateur ni un éventuel proxy ne peut la retrouver dans le cache. C'est comme si son nom avait changé, par exemple myscript-v2.js.
Je voulais dire : que va-ce changer par rapport à avoir simplement un last-modified modifié ? (au moins sur le fichier JS, sinon et y compris sur le fichier php hôte)
Je ne sais pas si lors du rafraichissement en cache d'un fichier html, le navigateur rafraichit aussi tout ce qui y est embarqué (images, scripts, etc.) ou seulement les éléments y modifiés (par leur seule date de modification).
Non, c'est indépendant. La requête HTTP pour le fichier JavaScript est indépendante de celle pour le fichier HTML.
Why that ? Et même ?
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les échanges navigateur/serveur permettent de rafraichir une page lorsque sa date d'Expire n'est pas atteinte alors que son last-modified a changé.
Je passe.
Pierre ?
-- sm
Le 11/25/08 11:53 AM, Olivier Miakinen a écrit :
Le 25/11/2008 10:50, SAM a écrit :
Ça ne m'était pas venu de suite à l'esprit, mais la solution la plus
simple est effectivement de rajouter un paramètre en GET dans l'appel au
fichier de script :
<script src="myscript.js?version=2.0"></script>
Je ne comprends rien à ton truc !
Je croyais que la page était bloquée dans le cache pendant 12 heures ?
Moi, ce que j'avais compris, c'était que la page HTML était bien
rechargée, mais pas le script myscript.js.
Je ne comprends pas pourquoi.
Si la page est rechargée, le navigateur devrait à minima s'assurer que
les éléments y inclus n'ont pas changé depuis la dernière visite, non ?
Sinon comment tester ses bricolages JS ?
Encore que parfois j'ai des problèmes de rafraichissement d'images
issues de CSS (tt du moins en local).
Que va-ce changer au problème d'avoir une légère variation de son code ?
L'URL du script étant différente, ni le navigateur ni un éventuel proxy
ne peut la retrouver dans le cache. C'est comme si son nom avait changé,
par exemple myscript-v2.js.
Je voulais dire : que va-ce changer par rapport à avoir simplement un
last-modified modifié ?
(au moins sur le fichier JS, sinon et y compris sur le fichier php hôte)
Je ne sais pas si lors du rafraichissement en cache d'un fichier html,
le navigateur rafraichit aussi tout ce qui y est embarqué (images,
scripts, etc.) ou seulement les éléments y modifiés (par leur seule date
de modification).
Non, c'est indépendant. La requête HTTP pour le fichier JavaScript est
indépendante de celle pour le fichier HTML.
Why that ?
Et même ?
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les
échanges navigateur/serveur permettent de rafraichir une page lorsque sa
date d'Expire n'est pas atteinte alors que son last-modified a changé.
Ça ne m'était pas venu de suite à l'esprit, mais la solution la plus simple est effectivement de rajouter un paramètre en GET dans l'appel au fichier de script :
<script src="myscript.js?version=2.0"></script>
Je ne comprends rien à ton truc ! Je croyais que la page était bloquée dans le cache pendant 12 heures ?
Moi, ce que j'avais compris, c'était que la page HTML était bien rechargée, mais pas le script myscript.js.
Je ne comprends pas pourquoi. Si la page est rechargée, le navigateur devrait à minima s'assurer que les éléments y inclus n'ont pas changé depuis la dernière visite, non ?
Sinon comment tester ses bricolages JS ?
Encore que parfois j'ai des problèmes de rafraichissement d'images issues de CSS (tt du moins en local).
Que va-ce changer au problème d'avoir une légère variation de son code ?
L'URL du script étant différente, ni le navigateur ni un éventuel proxy ne peut la retrouver dans le cache. C'est comme si son nom avait changé, par exemple myscript-v2.js.
Je voulais dire : que va-ce changer par rapport à avoir simplement un last-modified modifié ? (au moins sur le fichier JS, sinon et y compris sur le fichier php hôte)
Je ne sais pas si lors du rafraichissement en cache d'un fichier html, le navigateur rafraichit aussi tout ce qui y est embarqué (images, scripts, etc.) ou seulement les éléments y modifiés (par leur seule date de modification).
Non, c'est indépendant. La requête HTTP pour le fichier JavaScript est indépendante de celle pour le fichier HTML.
Why that ? Et même ?
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les échanges navigateur/serveur permettent de rafraichir une page lorsque sa date d'Expire n'est pas atteinte alors que son last-modified a changé.
Je passe.
Pierre ?
-- sm
SAM
Le 11/25/08 1:27 PM, Pascal PONCET a écrit :
Olivier Miakinen a écrit :
Le 25/11/2008 10:50, SAM a écrit :
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les échanges navigateur/serveur permettent de rafraichir une page lorsque sa date d'Expire n'est pas atteinte alors que son last-modified a changé.
Moi j'ai cru comprendre que non, tant que la date Expire n'est pas passée, aucune revalidation du cache n'est demandée au serveur.
donc il ne sert de rien de modifier le src du JS externe :-( (sauf après l'Expire et pour les navigateurs paresseux)
-- sm
Le 11/25/08 1:27 PM, Pascal PONCET a écrit :
Olivier Miakinen a écrit :
Le 25/11/2008 10:50, SAM a écrit :
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les
échanges navigateur/serveur permettent de rafraichir une page lorsque sa
date d'Expire n'est pas atteinte alors que son last-modified a changé.
Moi j'ai cru comprendre que non, tant que la date Expire n'est pas
passée, aucune revalidation du cache n'est demandée au serveur.
donc il ne sert de rien de modifier le src du JS externe :-(
(sauf après l'Expire et pour les navigateurs paresseux)
Dans le tutoriel de la mise en cache je n'ai pas bien compris si les échanges navigateur/serveur permettent de rafraichir une page lorsque sa date d'Expire n'est pas atteinte alors que son last-modified a changé.
Moi j'ai cru comprendre que non, tant que la date Expire n'est pas passée, aucune revalidation du cache n'est demandée au serveur.
donc il ne sert de rien de modifier le src du JS externe :-( (sauf après l'Expire et pour les navigateurs paresseux)
-- sm
Pierre Goiffon
SAM wrote:
http://www.mnot.net/cache_docs/index.fr.html
Ce n'est pa ça que je viens de donner ? (1h22 avant ton post)
Ha oui, dans <492ac111$0$932$ Mes plus sincères excuses, j'ai raté ton lien en bas de message, je suis allé trop vite. Désolé
SAM wrote:
http://www.mnot.net/cache_docs/index.fr.html
Ce n'est pa ça que je viens de donner ?
(1h22 avant ton post)
Ha oui, dans <492ac111$0$932$ba4acef3@news.orange.fr>
Mes plus sincères excuses, j'ai raté ton lien en bas de message, je suis
allé trop vite.
Désolé
Ce n'est pa ça que je viens de donner ? (1h22 avant ton post)
Ha oui, dans <492ac111$0$932$ Mes plus sincères excuses, j'ai raté ton lien en bas de message, je suis allé trop vite. Désolé
Pierre Goiffon
Pascal PONCET wrote:
Je reformule :
1. J'ai une page "index.php" qui, dans sa sortie Html, fait référence à un script externe (<script src="myscript.js">).
2. Un mois plus tard, je modifie le script "myscript.js" avec des effets visible (DHTML) sur la sortie Html de "index.php".
3. Certains internautes ne voient pas les effets de ces modifications, car ils ont conservé en cache l'ancienne version de "myscript.js".
Comment éviter la mise en cache dans ce cas, tout en conservant le bénéfice habituel du caching client ?
Ha merci, c'est beaucoup plus clair !
Immédiatement comme ça, je proposerai de changer l'appel à ce script ? Par exemple myscript.js?20081124 ?
Il n'existe pas de mécanisme pour depuis le serveur indiquer aux clients de mettre à jour une ressource donnée... Il y a la possibilité de demander à ce que le navigateur effectue un head pour vérifier si la ressource n'a pas été mise à jour, mais ça coûte en terme de connexion (limite du nombre de connexions par navigateur)
Le tout est de trouver le bon compromis, ce n'est pas évident...
Pascal PONCET wrote:
Je reformule :
1. J'ai une page "index.php" qui, dans sa sortie Html, fait référence à
un script externe (<script src="myscript.js">).
2. Un mois plus tard, je modifie le script "myscript.js" avec des effets
visible (DHTML) sur la sortie Html de "index.php".
3. Certains internautes ne voient pas les effets de ces modifications,
car ils ont conservé en cache l'ancienne version de "myscript.js".
Comment éviter la mise en cache dans ce cas, tout en conservant le
bénéfice habituel du caching client ?
Ha merci, c'est beaucoup plus clair !
Immédiatement comme ça, je proposerai de changer l'appel à ce script ?
Par exemple myscript.js?20081124 ?
Il n'existe pas de mécanisme pour depuis le serveur indiquer aux clients
de mettre à jour une ressource donnée...
Il y a la possibilité de demander à ce que le navigateur effectue un
head pour vérifier si la ressource n'a pas été mise à jour, mais ça
coûte en terme de connexion (limite du nombre de connexions par navigateur)
Le tout est de trouver le bon compromis, ce n'est pas évident...
1. J'ai une page "index.php" qui, dans sa sortie Html, fait référence à un script externe (<script src="myscript.js">).
2. Un mois plus tard, je modifie le script "myscript.js" avec des effets visible (DHTML) sur la sortie Html de "index.php".
3. Certains internautes ne voient pas les effets de ces modifications, car ils ont conservé en cache l'ancienne version de "myscript.js".
Comment éviter la mise en cache dans ce cas, tout en conservant le bénéfice habituel du caching client ?
Ha merci, c'est beaucoup plus clair !
Immédiatement comme ça, je proposerai de changer l'appel à ce script ? Par exemple myscript.js?20081124 ?
Il n'existe pas de mécanisme pour depuis le serveur indiquer aux clients de mettre à jour une ressource donnée... Il y a la possibilité de demander à ce que le navigateur effectue un head pour vérifier si la ressource n'a pas été mise à jour, mais ça coûte en terme de connexion (limite du nombre de connexions par navigateur)
Le tout est de trouver le bon compromis, ce n'est pas évident...
Pascal PONCET
SAM a écrit :
donc il ne sert de rien de modifier le src du JS externe :-( (sauf après l'Expire et pour les navigateurs paresseux)
Ben si, justement, parce que le cache considérera que c'est une ressource différente de celle qu'il avait précédemment stockée (se fiant à l'URL complète, y compris la partie en GET).
Conséquences :
1. le cache déclarera au navigateur qu'il n'a pas stocké cette ressource. 2. le navigateur enverra une requête standard au serveur. 3. le serveur retournera la ressource demandée soit, dans notre cas, le fichier JS dans sa dernière mouture.
Entendons-nous bien, ce micmac n'est utile (et nécessaire) que dans le cas où tout changement de comportement de la page HTML, piloté par du javascript déclaré externe et modifié en conséquence, doit être visible immédiatement après la mise en ligne dudit script (et pas le lendemain).
Donc, ce n'est une réelle préoccupation que lorsque : 1. les visites sont assez nombreuses et quotidiennes. 2. l'interactivité est importante, et gérée en DHTML. 3. le script n'est pas modifié trop souvent (sinon, le cache on s'en fout).
Je précise enfin que le site concerné gère des annonces professionnelles.
SAM a écrit :
donc il ne sert de rien de modifier le src du JS externe :-(
(sauf après l'Expire et pour les navigateurs paresseux)
Ben si, justement, parce que le cache considérera que c'est une
ressource différente de celle qu'il avait précédemment stockée (se fiant
à l'URL complète, y compris la partie en GET).
Conséquences :
1. le cache déclarera au navigateur qu'il n'a pas stocké cette ressource.
2. le navigateur enverra une requête standard au serveur.
3. le serveur retournera la ressource demandée soit, dans notre cas, le
fichier JS dans sa dernière mouture.
Entendons-nous bien, ce micmac n'est utile (et nécessaire) que dans le
cas où tout changement de comportement de la page HTML, piloté par du
javascript déclaré externe et modifié en conséquence, doit être visible
immédiatement après la mise en ligne dudit script (et pas le lendemain).
Donc, ce n'est une réelle préoccupation que lorsque :
1. les visites sont assez nombreuses et quotidiennes.
2. l'interactivité est importante, et gérée en DHTML.
3. le script n'est pas modifié trop souvent (sinon, le cache on s'en fout).
Je précise enfin que le site concerné gère des annonces professionnelles.
donc il ne sert de rien de modifier le src du JS externe :-( (sauf après l'Expire et pour les navigateurs paresseux)
Ben si, justement, parce que le cache considérera que c'est une ressource différente de celle qu'il avait précédemment stockée (se fiant à l'URL complète, y compris la partie en GET).
Conséquences :
1. le cache déclarera au navigateur qu'il n'a pas stocké cette ressource. 2. le navigateur enverra une requête standard au serveur. 3. le serveur retournera la ressource demandée soit, dans notre cas, le fichier JS dans sa dernière mouture.
Entendons-nous bien, ce micmac n'est utile (et nécessaire) que dans le cas où tout changement de comportement de la page HTML, piloté par du javascript déclaré externe et modifié en conséquence, doit être visible immédiatement après la mise en ligne dudit script (et pas le lendemain).
Donc, ce n'est une réelle préoccupation que lorsque : 1. les visites sont assez nombreuses et quotidiennes. 2. l'interactivité est importante, et gérée en DHTML. 3. le script n'est pas modifié trop souvent (sinon, le cache on s'en fout).
Je précise enfin que le site concerné gère des annonces professionnelles.
Pierre Goiffon
Pierre Goiffon wrote:
Immédiatement comme ça, je proposerai de changer l'appel à ce script ? Par exemple myscript.js?20081124 ?
C'est drôle, j'ai passé une bonne partie de la journée d'hier à m'intéresser au cache avec le framework Wicket. En passant de ci de la, tombé sur un document qui indique qu'il est préférable d'indiquer un no de version dans le nom de fichier plutôt qu'en QS : http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ L'argument employé de la config par défaut des proxy semble pertinent, considérant que Squid est un produit majoritairement déployé !
Pierre Goiffon wrote:
Immédiatement comme ça, je proposerai de changer l'appel à ce script ?
Par exemple myscript.js?20081124 ?
C'est drôle, j'ai passé une bonne partie de la journée d'hier à
m'intéresser au cache avec le framework Wicket. En passant de ci de la,
tombé sur un document qui indique qu'il est préférable d'indiquer un no
de version dans le nom de fichier plutôt qu'en QS :
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
L'argument employé de la config par défaut des proxy semble pertinent,
considérant que Squid est un produit majoritairement déployé !
Immédiatement comme ça, je proposerai de changer l'appel à ce script ? Par exemple myscript.js?20081124 ?
C'est drôle, j'ai passé une bonne partie de la journée d'hier à m'intéresser au cache avec le framework Wicket. En passant de ci de la, tombé sur un document qui indique qu'il est préférable d'indiquer un no de version dans le nom de fichier plutôt qu'en QS : http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ L'argument employé de la config par défaut des proxy semble pertinent, considérant que Squid est un produit majoritairement déployé !
Mickaël Wolff
SAM a écrit :
Je ne comprends pas pourquoi.
Optimisation foireuse ? :D
Si la page est rechargée, le navigateur devrait à minima s'assurer que les éléments y inclus n'ont pas changé depuis la dernière visite, non ?
Sinon comment tester ses bricolages JS ?
C'est la raison pour laquelle il y a la fonctionnalité « désactiver le cache » dans la Web Developper Toolbar pour Firefox.
Non, c'est indépendant. La requête HTTP pour le fichier JavaScript est indépendante de celle pour le fichier HTML.
Why that ?
Ça dépend du serveur et du navigateur, mais l'usage du HTTP mime multipart n'est pas très répandu.
