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>

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.

C'est un bug dans Firefox 3.5.

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

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;

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"]

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 /

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.

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>

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)

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.

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

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.