Este es un error en Firefox:

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

Pruebe esta solución:

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

<script>
var _theframe = document.getElementById("theframe");
_theframe.contentWindow.location.href = _theframe.src;
</script>

He sido capaz de solucionar este error estableciendo un atributo único name en el iframe - por cualquier razón, esto parece destruir la caché. Puede usar cualquier dato dinámico que tenga como atributo name, o simplemente el tiempo actual de ms o ns en cualquier lenguaje de plantillas que esté utilizando. Esta es una solución más agradable que las anteriores porque no requiere directamente JS.

En mi caso particular, el iframe se está construyendo a través de JS (pero podría hacer lo mismo a través de PHP, Ruby, lo que sea), así que simplemente uso Date.now():

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

Esto corrige el error en mis pruebas; probablemente porque el window.name en la ventana interna cambia.

Es un error en Firefox 3.5.

Echa un vistazo.. https://bugzilla.mozilla.org/show_bug.cgi?id=279048

Para que el iframe cargue siempre contenido nuevo, agregue la marca de tiempo Unix actual al final de los parámetros GET. El navegador lo ve como una solicitud 'diferente' y buscará nuevo contenido.

En Javascript, podría verse como:

frames['my_iframe'].location.href='load_iframe_content.php?group_ID=' + group_ID + '&timestamp=' + timestamp;

Después de probar todo lo demás (excepto usar un proxy para el contenido de iframe), encontré una manera de evitar el almacenamiento en caché de contenido de iframe, desde el mismo dominio :

Use .htaccess y una regla de reescritura y cambie el atributo iframe src.

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

La forma en que uso esto es que la URL del iframe termina mirando de esta manera: example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html

Donde [token] es un valor generado aleatoriamente. Esta URL impide el almacenamiento en caché de iframe, ya que el token nunca es el mismo, y el iframe piensa es una página web totalmente diferente ya que una sola actualización carga una URL totalmente diferente :

example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html
example.com/test/54/d2cc21be7cdcb5a1f989272706de1913.html

Ambos conducen a la misma página.

Puede acceder a sus parámetros de url ocultos con $_SERVER["QUERY_STRING"]

Establecí el atributo iframe src más adelante en mi aplicación. Para deshacerse del contenido en caché dentro de iframe al inicio de la aplicación simplemente hago:

myIframe.src = "";

... en algún lugar al principio del código js (por ejemplo en jquery hand () handler)

Gracias a http://www.freshsupercool.com/2008/07/10/firefox-caching-iframe-data /

He encontrado este problema en la última Chrome, así como la última Safari en el Mac OS X a partir de Mar 17, 2016. Ninguna de las correcciones anteriores funcionó para mí, incluida la asignación de src para vaciar y luego volver a algún sitio, o agregar un parámetro "name" con nombre aleatorio, o agregar un número aleatorio al final de la URL después del hash, o asignar la ventana de contenido href al src después de asignar el src.

En mi caso, fue porque estaba usando Javascript para actualizar el IFRAME, y solo cambiar el hash en la URL.

La solución en mi caso fue que creé una URL provisional que tenía un meta redireccionamiento de 0 segundos a esa otra página. Sucede tan rápido que apenas noto el flash de la pantalla. Además, hice que el color de fondo de la página provisional sea el mismo que el de la otra página, por lo que se nota aún menos.

También tuve este problema en 2016 con iOS Safari. Lo que parecía funcionar para mí era dar un parámetro GET al iframe src y un valor para él como este

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

Como ha dicho, el problema aquí no es iframe content caching, sino iframe url caching.

A partir de septiembre de 2018, parece que el problema todavía se produce en Chrome, pero no en Firefox.

He intentado muchas cosas (agregar un parámetro GET cambiante, borrar la url del iframe en onbeforeunload, detectar un "reload from cache" usando una cookie, configurar varios encabezados de respuesta) y aquí están las únicas dos soluciones que funcionaron desde mí:

1- Manera fácil: crear su iframe dinámicamente desde javascript

Por ejemplo:

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

2- forma Enrevesada

Del lado del servidor, como se explica aquí, deshabilite el almacenamiento en caché del contenido para el contenido que sirve para el iframe O para la página padre (cualquiera de los dos lo hará).

Y

Establezca la url del iframe desde javascript con un parámetro de búsqueda adicional, como este:

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

(versión simplificada, cuidado con otros parámetros de búsqueda)

¿Ha instalado Fiddler2 ?

Le permitirá ver exactamente lo que se está solicitando, lo que se está enviando de vuelta, etc. No parece plausible que el navegador realmente golpee su caché para diferentes URL.

¿Ha intentado agregar las diversas opciones de encabezado HTTP para no-cache a la página iframe?

Si desea que realmente se vuelva loco, podría implementar el nombre de la página como una url dinámica que siempre se resuelve en la misma página, en lugar de la opción querystring?

Suponiendo que esté en una oficina, compruebe si hay algún almacenamiento en caché a nivel de red. Créeme, es una posibilidad. Su gente de TI podrá decirle si hay alguna infraestructura de red alrededor del almacenamiento en caché HTTP, aunque como esto solo sucede para el iframe, es poco probable.