Prévention de la mise en cache d'iframe dans le navigateur

comment empêcher Firefox et Safari de cacher le contenu d'iframe?

j'ai une page Web simple avec une iframe à une page sur un site différent. Tant la page externe que la page interne ont des en-têtes de réponse HTTP pour empêcher la mise en cache. Lorsque je clique sur le bouton" Retour " du navigateur, la page extérieure fonctionne correctement, mais quoi qu'il arrive, le navigateur récupère toujours une cache de la page iframed. IE fonctionne très bien, mais Firefox et Safari me posent problème.

ma page Web ressemble à quelque chose comme ceci:

<html>
  <head><!-- stuff --></head>
<body>
  <!-- stuff -->
  <iframe src="webpage2.html?var=xxx" />
  <!-- stuff -->
</body>
</html>

la variable var change toujours. Malgré le fait que L'URL de l'iframe a changé (et donc, le navigateur devrait faire une nouvelle demande à cette page), le navigateur ne fait que récupérer le contenu mis en cache.

j'ai examiné les requêtes HTTP et les réponses allant et venant, et j'ai remarqué que même si la page externe contient <iframe src="webpage2.html?var=222" /> , le navigateur va toujours chercher webpage2.html?var=111 .

voici ce que j'ai essayé jusqu'à présent:

  • Changer iframe URL aléatoire var valeur
  • ajout des en-têtes Expires, Cache-Control et Pragma à la page Web externe
  • ajouter des en-têtes Expires, Cache-Control et Pragma à la page Web intérieure

je suis incapable de faire des trucs JavaScript parce que je suis bloqué par la Politique de la même origine.

je suis à court d'idées. Quelqu'un sait-il comment empêcher le navigateur de mettre en cache le contenu iframed?

mise à Jour

j'ai installé Fiddler2 comme Daniel me l'a suggéré pour effectuer un autre test, et malheureusement, j'obtiens toujours les mêmes résultats.

C'est le test que j'ai effectué:

  1. la page extérieure génère un numéro aléatoire en utilisant Math.random() dans JSP.
  2. page extérieure affiche nombre aléatoire sur la page web.
  3. la page extérieure appelle iframe, en passant en nombre aléatoire.
  4. page intérieure affiche un nombre aléatoire.

avec ce test, je suis capable de voir exactement quelles pages sont mises à jour, et quelles pages sont mises en cache.

Test Visuel

Pour un test rapide, je charge la page, accédez à une autre page, puis appuyez sur "retour."Voici les résultats:

Page Originale:

  • Externe Page: 0.21300034290246206
  • Inner Page: 0.21300034290246206

Quitter la page, puis en appuyant sur retour:

  • Externe page: 0.4470929019483644
  • Inner page: 0.21300034290246206

cela montre que la page intérieure est mise en cache, bien que la page extérieure appelle avec un paramètre GET différent dans L'URL. Pour une raison quelconque, le navigateur ignore le fait que l'iframe demande une nouvelle URL; il charge simplement l'ancienne.

Fiddler Test

bien sûr, Fiddler confirme la même chose.

(je charge la page.)

la page extérieure s'appelle. HTML:

0.21300034290246206
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.21300034290246206" />

http://ipv4.fiddler: 1416 / page1.aspx?var=0,21300034290246206 s'appelle.

(je navigue loin de la page et puis j'appuie en arrière.)

la page extérieure s'appelle. HTML:

0.4470929019483644
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.4470929019483644" />

http://ipv4.fiddler: 1416 / page1.aspx?var=0.21300034290246206 s'appelle.

Eh bien, à partir de ce test, il semble que le navigateur web ne cache pas la page, mais il cache L'URL de l'iframe et fait ensuite une nouvelle demande sur cette URL mise en cache. Cependant, je suis toujours perplexe quant à la façon de résoudre ce problème.

est-ce que quelqu'un a des idées sur la façon d'empêcher le navigateur web de cacher les URL iframe?

74
demandé sur JR. 2010-04-15 22:40:11

13 réponses

l'URL de l'iframe pointer vers une page de votre site qui agit comme un proxy pour récupérer et renvoyer le contenu de l'iframe. Maintenant vous n'êtes plus lié par la politique de " même origine.

1
répondu kmoser 2010-06-29 16:50:00

C'est un bug dans Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=356558

essayez cette solution:

<iframe src="webpage2.html?var=xxx" id="theframe"></iframe>

<script>
var _theframe = document.getElementById("theframe");
_theframe.contentWindow.location.href = _theframe.src;
</script>
45
répondu Caleb 2010-10-21 03:30:10

j'ai pu contourner ce bug en mettant un attribut unique name sur l'iframe - pour quelque raison que ce soit, cela semble détruire le cache. Vous pouvez utiliser toutes les données dynamiques que vous avez comme attribut name - ou simplement l'heure ms ou ns actuelle dans n'importe quel langage de templation que vous utilisez. C'est une solution plus agréable que celles ci-dessus parce qu'elle ne nécessite pas directement JS.

dans mon cas particulier, l'iframe est construit via JS (mais vous pourrait faire la même chose via PHP, Ruby, peu importe), donc j'utilise simplement Date.now() :

return '<iframe src="' + src + '" name="' + Date.now() + '" />';

cela corrige le bug dans mes tests; probablement parce que le window.name dans la fenêtre interne change.

26
répondu STRML 2014-10-04 08:47:29

C'est un bug dans Firefox 3.5.

Avoir un coup d'oeil.. https://bugzilla.mozilla.org/show_bug.cgi?id=279048

3
répondu renga 2011-03-23 06:03:10

pour que l'iframe charge toujours du contenu frais, ajoutez L'horodatage Unix actuel à la fin des paramètres GET. Le navigateur considère alors qu'il s'agit d'une demande "différente" et recherchera du nouveau contenu.

en Javascript, il pourrait ressembler à:

frames['my_iframe'].location.href='load_iframe_content.php?group_ID=' + group_ID + '&timestamp=' + timestamp;
3
répondu Division Six 2014-05-12 21:36:50

après avoir essayé tout le reste (sauf utiliser un proxy pour le contenu iframe), j'ai trouvé un moyen d'empêcher la mise en cache du contenu iframe, du même domaine :

utilisez .htaccess et une règle de réécriture et changez l'attribut iframe src .

RewriteRule test/([0-9]+)/([a-zA-Z0-9]+).html$ /test/index.php?idEntity=&token= [QSA]

la façon dont j'utilise ceci est que L'URL de l'iframe finit par ressembler à ceci: example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html

où [jeton] est une valeur aléatoire. Cette URL empêche la mise en cache d'iframe puisque le token n'est jamais le même, et l'iframe pense qu'il s'agit d'une page web totalement différente puisqu'un seul rafraîchissement charge une URL totalement différente :

example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html

example.com/test/54/d2cc21be7cdcb5a1f989272706de1913.html

mènent tous les deux à la même page.

vous pouvez accéder à vos paramètres d'url cachés avec $_SERVER["QUERY_STRING"]

3
répondu Jeff Noel 2015-04-22 17:41:56

j'ai défini l'attribut iframe src plus tard dans mon application. Pour se débarrasser du contenu caché à l'intérieur d'iframe au début de l'application je fais simplement:

myIframe.src = "";

... quelque part au début du code js (par exemple dans jQuery $ () handler)

grâce à http://www.freshsupercool.com/2008/07/10/firefox-caching-iframe-data /

2
répondu janekw 2012-04-18 09:10:48

j'ai trouvé ce problème dans le dernier Chrome ainsi que la dernière Safari sur le Mac OS X à partir de mars 17, 2016. Aucun des correctifs ci-dessus n'a fonctionné pour moi, y compris l'affectation de src à vide puis de nouveau à un site, ou l'ajout d'un paramètre nommé au hasard "name", ou l'ajout d'un nombre aléatoire à la fin de L'URL après le hachage, ou l'affectation de la fenêtre de contenu href au src après avoir assigné le src.

dans mon cas, c'était parce que J'utilisais Javascript pour mettre à jour L'IFRAME, et seulement la commutation du hachage dans L'URL.

la solution dans mon cas était que j'ai créé une URL provisoire qui avait une méta redirection 0 seconde à cette autre page. Ça se passe si vite que je remarque à peine le flash de l'écran. De plus, j'ai fait la couleur de fond de la page intérimaire la même que l'autre page, et donc vous le remarquez encore moins.

2
répondu Volomike 2016-03-17 19:51:10

j'ai également eu ce problème en 2016 avec iOS Safari. Ce qui semblait fonctionner pour moi était donner un paramètre GET à l'iframe src et une valeur pour lui comme ceci



<iframe width="60%" src="../other/url?cachebust=1" allowfullscreen></iframe>

0
répondu Lauri Kääriäinen 2016-08-06 13:16:43

comme vous l'avez dit, le problème ici n'est pas iframe content caching , mais iframe url caching .

en date de septembre 2018, il semble que le problème se produit toujours dans le Chrome, mais pas dans Firefox.

j'ai essayé plusieurs choses (ajout d'un paramètre GET changeant, suppression de l'url iframe dans onbeforeunload, détection d'un" reload from cache " à l'aide d'un cookie, configuration de divers en-têtes de réponse) et voici les deux seuls des solutions qui ont fonctionné de moi:

1-Easy way: créez votre iframe dynamiquement à partir de javascript

par exemple:

const iframe = document.createElement('iframe')
iframe.id = ...
...
iframe.src = myIFrameUrl 
document.body.appendChild(iframe)

2 - Alambiqué façon

côté serveur, comme expliqué ici , désactiver la mise en cache de contenu pour le contenu que vous servez pour l'iframe ou pour la page mère (l'un ou l'autre fera).

et

définit l'url iframe de javascript avec un changement supplémentaire de recherche param, comme ceci:

const url = myIFrameUrl + '?timestamp=' + new Date().getTime()
document.getElementById('my-iframe-id').src = url

(version simplifiée, attention aux autres paramètres de recherche)

0
répondu steph643 2018-09-25 22:18:22

avez-vous installé Fiddler2 ?

il vous permettra de voir exactement ce qui est demandé, ce qui est renvoyé, etc. Il n'est pas plausible que le navigateur ait vraiment atteint sa cache pour des URLs différentes.

-1
répondu Daniel Earwicker 2010-04-15 18:43:00

avez-vous essayé d'ajouter les différentes options D'en-tête HTTP pour no-cache à la page iframe?

-1
répondu Chris Webb 2010-10-06 09:57:54

si vous voulez obtenir vraiment fou vous pourriez mettre en œuvre le nom de page comme une url dynamique qui se résout toujours à la même page, plutôt que l'option querystring?

si vous êtes dans un bureau, Vérifiez s'il y a une mise en cache au niveau du réseau. Croyez-moi, c'est une possibilité. Vos responsables informatiques seront en mesure de vous dire s'il existe une infrastructure réseau autour de la mise en cache HTTP, bien que cela n'arrive que pour l'iframe c'est peu probable.

-1
répondu Chris Webb 2010-10-07 10:43:03