J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
la prise en compte par FF et IE a été curieuse : d'abord une qui change
(après un double refresh), puis l'autre après un clic de plus.
Si je mets un /far future Expires header/ sur js, css et images, que se
passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur
donner un numéro de version (dans le cadre d'un album photo, c'est ok
puisque les photos portent un nom, mais c'est autre chose pour le design) ?
Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises
que ça ralentissait pas mal le serveur et posait des problèmes (j'ai
oublié lesquels) par ailleurs.
Alors si vous avez connaissances et expériences en la matière, je prends
volontiers vos conseils :)
Merci.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SAM
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Comme d'hab on rappelle : <http://www.mnot.net/cache_docs/index.fr.html>
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est. Normalement, pour tout fichier à charger, le navigateur envoie un questionnement à propos de la dernière modif du fichier et devrait charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ? Y a pas de cache côté serveur et des histoires de sessions ?
la prise en compte par FF et IE a été curieuse : d'abord une qui change (après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en re-validant l'url (clic dans barre adresse et touche retour) afin de recharger la page.
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est. Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en cache dans le temps ?
passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur donner un numéro de version (dans le cadre d'un album photo, c'est ok puisque les photos portent un nom, mais c'est autre chose pour le design) ?
Quoi le design ? Les images incluses dans la feuille de style ? à mon idée, il faut re-uploader le fichier css en plus d'avoir modifié le design d'une image appelée par css et qui n'a pas changé de nom.
Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises que ça ralentissait pas mal le serveur et posait des problèmes (j'ai oublié lesquels) par ailleurs.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a toujours le JS
<body onload="var i=document.getElementById('pub'),d = new Date(); i.src = i.src+'?'+d;">
Alors si vous avez connaissances et expériences en la matière, je prends volontiers vos conseils :)
Comme on n'a pas essayé avec toi on a fait ce qu'on a pu ;-)
-- sm
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.
Comme d'hab on rappelle :
<http://www.mnot.net/cache_docs/index.fr.html>
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est.
Normalement, pour tout fichier à charger, le navigateur envoie un
questionnement à propos de la dernière modif du fichier et devrait
charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ?
Y a pas de cache côté serveur et des histoires de sessions ?
la prise en compte par FF et IE a été curieuse : d'abord une qui change
(après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en
re-validant l'url (clic dans barre adresse et touche retour) afin de
recharger la page.
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est.
Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en
cache dans le temps ?
passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur
donner un numéro de version (dans le cadre d'un album photo, c'est ok
puisque les photos portent un nom, mais c'est autre chose pour le design) ?
Quoi le design ?
Les images incluses dans la feuille de style ?
à mon idée, il faut re-uploader le fichier css en plus d'avoir modifié
le design d'une image appelée par css et qui n'a pas changé de nom.
Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises
que ça ralentissait pas mal le serveur et posait des problèmes (j'ai
oublié lesquels) par ailleurs.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a
toujours le JS
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Comme d'hab on rappelle : <http://www.mnot.net/cache_docs/index.fr.html>
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est. Normalement, pour tout fichier à charger, le navigateur envoie un questionnement à propos de la dernière modif du fichier et devrait charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ? Y a pas de cache côté serveur et des histoires de sessions ?
la prise en compte par FF et IE a été curieuse : d'abord une qui change (après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en re-validant l'url (clic dans barre adresse et touche retour) afin de recharger la page.
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est. Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en cache dans le temps ?
passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur donner un numéro de version (dans le cadre d'un album photo, c'est ok puisque les photos portent un nom, mais c'est autre chose pour le design) ?
Quoi le design ? Les images incluses dans la feuille de style ? à mon idée, il faut re-uploader le fichier css en plus d'avoir modifié le design d'une image appelée par css et qui n'a pas changé de nom.
Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises que ça ralentissait pas mal le serveur et posait des problèmes (j'ai oublié lesquels) par ailleurs.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a toujours le JS
<body onload="var i=document.getElementById('pub'),d = new Date(); i.src = i.src+'?'+d;">
Alors si vous avez connaissances et expériences en la matière, je prends volontiers vos conseils :)
Comme on n'a pas essayé avec toi on a fait ce qu'on a pu ;-)
-- sm
yamo'
Salut,
Olivier Masson a tapoté, le 22/10/2009 09:51:
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de changer le nom du fichier. Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de fichiers, paramètre qui serait mis à jour lors de la modification d'un fichier, j'ai l'impression que drupal6 fait ça.
-- Stéphane <http://pasdenom.info/fortune> On construit des maisons de fous pour faire croire à ceux qui n'y sont pas enfermés qu'ils ont encore la raison. -+- Michel de Montaigne -+-
Salut,
Olivier Masson a tapoté, le 22/10/2009 09:51:
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en
compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de
changer le nom du fichier.
Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de
fichiers, paramètre qui serait mis à jour lors de la modification d'un
fichier, j'ai l'impression que drupal6 fait ça.
--
Stéphane
<http://pasdenom.info/fortune>
On construit des maisons de fous pour faire croire à ceux
qui n'y sont pas enfermés qu'ils ont encore la raison.
-+- Michel de Montaigne -+-
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de changer le nom du fichier. Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de fichiers, paramètre qui serait mis à jour lors de la modification d'un fichier, j'ai l'impression que drupal6 fait ça.
-- Stéphane <http://pasdenom.info/fortune> On construit des maisons de fous pour faire croire à ceux qui n'y sont pas enfermés qu'ils ont encore la raison. -+- Michel de Montaigne -+-
SAM
Le 10/22/09 11:09 AM, SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
la prise en compte par FF et IE a été curieuse : d'abord une qui change (après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en re-validant l'url (clic dans barre adresse et touche retour) afin de recharger la page.
Ha! Ben bon ! c'est le contraire (Firefox)
-- sm
Le 10/22/09 11:09 AM, SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
la prise en compte par FF et IE a été curieuse : d'abord une qui
change (après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en
re-validant l'url (clic dans barre adresse et touche retour) afin de
recharger la page.
la prise en compte par FF et IE a été curieuse : d'abord une qui change (après un double refresh), puis l'autre après un clic de plus.
À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en re-validant l'url (clic dans barre adresse et touche retour) afin de recharger la page.
Ha! Ben bon ! c'est le contraire (Firefox)
-- sm
Olivier Masson
SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Comme d'hab on rappelle : <http://www.mnot.net/cache_docs/index.fr.html>
Oui mais cette doc indique ce qui devrait se passer normalement. Et ce que je constate ne colle pas.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est. Normalement, pour tout fichier à charger, le navigateur envoie un questionnement à propos de la dernière modif du fichier et devrait charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ? Y a pas de cache côté serveur et des histoires de sessions ?
Du tout. Pas de mise en cache, pas de sessions et adresse tapée dans un nav fraichement ouvert. Oui, même heure (serveur ntp). Et pourquoi il mettrait UNE photo à jour et pas l'autre ? Même comportement sur un autre ordi (Safari Mac).
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est. Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en cache dans le temps ?
La doc de mnot en parle : "If a resource (especially a downloadable file) changes, change its name. That way, you can make it *expire far in the future*, and still guarantee that the correct version is served; the page that links to it is the only one that will need a short expiry time"
Et c'est la technique la plus commune (puisqu'elle fonctionne). Quand je dis commune, je parle de sites "pro". Je veux bien utiliser ça, mais je ne vois pas pourquoi je dois utiliser ça plutôt qu'un Last-Modified.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a toujours le JS
non merci :)
SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.
Comme d'hab on rappelle :
<http://www.mnot.net/cache_docs/index.fr.html>
Oui mais cette doc indique ce qui devrait se passer normalement. Et ce
que je constate ne colle pas.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est.
Normalement, pour tout fichier à charger, le navigateur envoie un
questionnement à propos de la dernière modif du fichier et devrait
charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ?
Y a pas de cache côté serveur et des histoires de sessions ?
Du tout. Pas de mise en cache, pas de sessions et adresse tapée dans un
nav fraichement ouvert.
Oui, même heure (serveur ntp).
Et pourquoi il mettrait UNE photo à jour et pas l'autre ?
Même comportement sur un autre ordi (Safari Mac).
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est.
Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en
cache dans le temps ?
La doc de mnot en parle :
"If a resource (especially a downloadable file) changes, change its
name. That way, you can make it *expire far in the future*, and still
guarantee that the correct version is served; the page that links to it
is the only one that will need a short expiry time"
Et c'est la technique la plus commune (puisqu'elle fonctionne). Quand je
dis commune, je parle de sites "pro".
Je veux bien utiliser ça, mais je ne vois pas pourquoi je dois utiliser
ça plutôt qu'un Last-Modified.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a
toujours le JS
J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en cache côté client.
Comme d'hab on rappelle : <http://www.mnot.net/cache_docs/index.fr.html>
Oui mais cette doc indique ce qui devrait se passer normalement. Et ce que je constate ne colle pas.
Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
Usuellement ça l'est. Normalement, pour tout fichier à charger, le navigateur envoie un questionnement à propos de la dernière modif du fichier et devrait charger celui-là s'il est plus récent que celui en cache.
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
Et bien sûr ton ordi est exactement à la même heure que le serveur ? Y a pas de cache côté serveur et des histoires de sessions ?
Du tout. Pas de mise en cache, pas de sessions et adresse tapée dans un nav fraichement ouvert. Oui, même heure (serveur ntp). Et pourquoi il mettrait UNE photo à jour et pas l'autre ? Même comportement sur un autre ordi (Safari Mac).
Si je mets un /far future Expires header/ sur js, css et images, que se
Je sais pô c'que c'est. Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en cache dans le temps ?
La doc de mnot en parle : "If a resource (especially a downloadable file) changes, change its name. That way, you can make it *expire far in the future*, and still guarantee that the correct version is served; the page that links to it is the only one that will need a short expiry time"
Et c'est la technique la plus commune (puisqu'elle fonctionne). Quand je dis commune, je parle de sites "pro". Je veux bien utiliser ça, mais je ne vois pas pourquoi je dois utiliser ça plutôt qu'un Last-Modified.
Ben alorsse si c'est pour rafraichir une image (genre pub) il y a toujours le JS
non merci :)
Olivier Masson
yamo' a écrit :
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de changer le nom du fichier. Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de fichiers, paramètre qui serait mis à jour lors de la modification d'un fichier, j'ai l'impression que drupal6 fait ça.
Oui, c'est la technique du /far future Expires header/ qui est la seule que j'ai effectivement vu fonctionner à coup sûr. Si Drupal le fait, c'est donc probablement que la solution classique ne fonctionne pas ou peu (si ç'avait été joomla, je n'y aurais pas autant cru :))
yamo' a écrit :
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en
compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de
changer le nom du fichier.
Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de
fichiers, paramètre qui serait mis à jour lors de la modification d'un
fichier, j'ai l'impression que drupal6 fait ça.
Oui, c'est la technique du /far future Expires header/ qui est la seule
que j'ai effectivement vu fonctionner à coup sûr.
Si Drupal le fait, c'est donc probablement que la solution classique ne
fonctionne pas ou peu (si ç'avait été joomla, je n'y aurais pas autant
cru :))
Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de changer le nom du fichier. Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de fichiers, paramètre qui serait mis à jour lors de la modification d'un fichier, j'ai l'impression que drupal6 fait ça.
Oui, c'est la technique du /far future Expires header/ qui est la seule que j'ai effectivement vu fonctionner à coup sûr. Si Drupal le fait, c'est donc probablement que la solution classique ne fonctionne pas ou peu (si ç'avait été joomla, je n'y aurais pas autant cru :))
