Impedire la memorizzazione nella cache iframe nel browser

88

Come si impedisce a Firefox e Safari di memorizzare nella cache i contenuti iframe?

Ho una semplice pagina web con un iframe a una pagina su un sito diverso. Sia la pagina esterna che quella interna hanno intestazioni di risposta HTTP per impedire la memorizzazione nella cache. Quando faccio clic sul pulsante "indietro" nel browser, la pagina esterna funziona correttamente, ma non importa cosa, il browser recupera sempre una cache della pagina iframe. IE funziona bene, ma Firefox e Safari mi stanno dando problemi.

La mia pagina web ha un aspetto simile a questo:

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

La varvariabile cambia sempre. Nonostante il fatto che l'URL dell'iframe sia cambiato (e quindi, il browser dovrebbe fare una nuova richiesta a quella pagina), il browser recupera semplicemente il contenuto memorizzato nella cache.

Ho esaminato le richieste e le risposte HTTP andando avanti e indietro e ho notato che anche se la pagina esterna contiene <iframe src="webpage2.html?var=222" />, il browser continuerà a recuperare webpage2.html?var=111.

Ecco cosa ho provato finora:

  • Modifica dell'URL iframe con un valore var casuale
  • Aggiunta di intestazioni Expires, Cache-Control e Pragma alla pagina Web esterna
  • Aggiunta di intestazioni Expires, Cache-Control e Pragma alla pagina web interna

Non sono in grado di eseguire trucchi JavaScript perché sono bloccato dal criterio della stessa origine.

Sto esaurendo le idee. Qualcuno sa come impedire al browser di memorizzare nella cache il contenuto iframed?

Aggiornare

Ho installato Fiddler2 come suggerito da Daniel per eseguire un altro test e, sfortunatamente, ottengo ancora gli stessi risultati.

Questo è il test che ho eseguito:

  1. La pagina esterna genera un numero casuale utilizzando Math.random()in JSP.
  2. La pagina esterna mostra un numero casuale sulla pagina web.
  3. La pagina esterna chiama iframe, passando un numero casuale.
  4. La pagina interna mostra un numero casuale.

Con questo test, sono in grado di vedere esattamente quali pagine vengono aggiornate e quali sono memorizzate nella cache.

Test visivo

Per un rapido test, carico la pagina, passo a un'altra pagina, quindi premo "indietro". Ecco i risultati:

Pagina originale:

  • Pagina esterna: 0.21300034290246206
  • Pagina interna: 0.21300034290246206

Lasciando la pagina, quindi colpendo di nuovo:

  • Pagina esterna: 0.4470929019483644
  • Pagina interna: 0.21300034290246206

Ciò mostra che la pagina interna viene memorizzata nella cache, anche se la pagina esterna la chiama con un diverso parametro GET nell'URL. Per qualche ragione, il browser ignora il fatto che l'iframe richiede un nuovo URL; carica semplicemente quello vecchio.

Fiddler Test

Abbastanza sicuro, Fiddler conferma la stessa cosa.

(Carico la pagina.)

Viene chiamata la pagina esterna. HTML:

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

http: //ipv4.fiddler: 1416 / page1.aspx? var = 0.21300034290246206 viene chiamato.

(Esco dalla pagina e poi rispondo.)

Viene chiamata la pagina esterna. HTML:

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

http: //ipv4.fiddler: 1416 / page1.aspx? var = 0.21300034290246206 viene chiamato.

Bene, da questo test, sembra che il browser Web non memorizzi la pagina nella cache, ma memorizzi nella cache l'URL dell'iframe e quindi effettui una nuova richiesta su quell'URL memorizzato nella cache. Tuttavia, sono ancora perplesso su come risolvere questo problema.

Qualcuno ha qualche idea su come impedire al browser Web di memorizzare nella cache gli URL iframe?

browser  caching  iframe  back-button 
— JR.
fonte
11
+1 - La tua scrittura cattura così bene il dolore.
— nickf
1
Grazie per la spiegazione molto dettagliata del problema, questo è esattamente quello che sto sperimentando al 100% con un sito. Sono passati sette anni e la segnalazione di bug di Firefox è ancora presente.
— Scuzzy

Risposte:

-3

Fai in modo che l'URL dell'iframe punti a una pagina del tuo sito che funge da proxy per recuperare e restituire i contenuti effettivi dell'iframe. Ora non sei più vincolato dalla politica della stessa origine (EDIT: non impedisce il problema della memorizzazione nella cache dell'iframe).

— kmoser
fonte
41
questo non impedisce la cache.
— baash05
@ baash05 non ho mai affermato di averlo fatto; Ho detto che evita la politica della stessa origine.
— kmoser
1
Vero .. ma il titolo dell'operazione è "Prevenire la memorizzazione nella cache dell'iframe nel browser" e se la tua risposta non impedisce la memorizzazione nella cache dell'iframe nel browser, non è proprio una risposta. È carino da sapere, ma non è ancora un buon consiglio per chi cerca di impedire la memorizzazione nella cache.
— baash05
OP stava cercando di risolvere il caching ed evitare la politica della stessa origine. Una risposta parziale è meglio di niente :)
— kmoser
2
il toast cade sempre con la marmellata
— rivolta
59

Questo è un bug in Firefox:

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

Prova questa soluzione alternativa:

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

<script>
var _theframe = document.getElementById("theframe");
_theframe.contentWindow.location.href = _theframe.src;
</script>
— Caleb
fonte
3
Oggi 27.2.2014 sono così felice di aver trovato questo thread, ho pensato che potesse essere risolto senza cache lato server. FF 27 ha ancora questo bug.
— Robert,
7
7.8.2014 - 8 anni dopo e ancora non risolto.
— Łukasz Zaroda
Questo vale anche per l'attributo srcdoc, così strano ... Così grato di averlo trovato.
— elundmark
2
Ho trovato lo stesso problema di memorizzazione nella cache con Chrome e le due righe di JavaScript lo hanno risolto. Grazie!
— Thorn
2
Wow, ha avuto lo stesso identico problema. Era specifico per Firefox - funzionava bene in IE, Chrome, ecc. Grazie @caleb. Non posso credere che sia durato così a lungo.
— Voodoo
33

Sono stato in grado di aggirare questo bug impostando un nameattributo univoco sull'iframe - per qualsiasi motivo, questo sembra rompere la cache. Puoi usare qualsiasi dato dinamico che hai come nameattributo, o semplicemente il tempo ms o ns corrente in qualunque linguaggio di template stai usando. Questa è una soluzione migliore di quelle sopra perché non richiede direttamente JS.

Nel mio caso particolare, l'iframe viene creato tramite JS (ma potresti fare lo stesso tramite PHP, Ruby, qualunque cosa), quindi uso semplicemente Date.now():

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

Questo risolve il bug nel mio test; probabilmente perché window.namecambia la finestra interna.

— STRML
fonte
2
Questa risposta funziona per Chrome, Firefox e Safari dalla fine del 2015.
— rovermicrover
13

Come hai detto, il problema qui non è la memorizzazione nella cache dei contenuti iframe , ma la memorizzazione nella cache degli URL iframe .

A partire da settembre 2018, sembra che il problema si verifichi ancora in Chrome ma non in Firefox.

Ho provato molte cose (aggiungendo un parametro GET modificabile, cancellando l'URL dell'iframe in onbeforeunload, rilevando un "ricaricamento dalla cache" utilizzando un cookie, impostando varie intestazioni di risposta) e qui ci sono le uniche due soluzioni che hanno funzionato da me:

1- Un modo semplice: crea il tuo iframe dinamicamente da javascript

Per esempio:

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

2- Modo contorto

Lato server, come spiegato qui , disabilita la memorizzazione nella cache dei contenuti per il contenuto che offri per l'iframe OPPURE per la pagina padre (lo faranno entrambi).

E

Imposta l'URL dell'iframe da javascript con un ulteriore parametro di ricerca modificabile, come questo:

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

(versione semplificata, attenzione ad altri parametri di ricerca)

— steph643
fonte
5

Dopo aver provato tutto il resto (tranne l'utilizzo di un proxy per il contenuto dell'iframe), ho trovato un modo per impedire la memorizzazione nella cache dei contenuti dell'iframe, dallo stesso dominio :

Usa .htaccesse una regola di riscrittura e modifica l' srcattributo iframe .

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

Il modo in cui lo uso è che l'URL dell'iframe finisce per apparire in questo modo: example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html

Dove [token] è un valore generato casualmente. Questo URL impedisce la memorizzazione nella cache dell'iframe poiché il token non è mai lo stesso e l'iframe pensa che sia una pagina web completamente diversa poiché un singolo aggiornamento carica un URL completamente diverso:

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

entrambi portano alla stessa pagina.

Puoi accedere ai parametri dell'URL nascosto con $_SERVER["QUERY_STRING"]

— Jeff Noel
fonte
1
Ha funzionato per me - Grazie!
— Quinn Finney
@QuinnFinney Sono contento che questo sia stato utile a qualcun altro. Ci sono voluti alcuni giorni per risolvere questo problema :)
— Jeff Noel
Si, anch'io! hahaha
— Quinn Finney
3

Per fare in modo che l'iframe carichi sempre nuovi contenuti, aggiungi il timestamp Unix corrente alla fine dei parametri GET. Il browser quindi la vede come una richiesta "diversa" e cercherà nuovi contenuti.

In Javascript, potrebbe essere simile a:

frames['my_iframe'].location.href='load_iframe_content.php?group_ID=' + group_ID + '&timestamp=' + timestamp;
— Divisione sei
fonte
3

Ho trovato questo problema nell'ultimo Chrome e nell'ultimo Safari su Mac OS X a partire dal 17 marzo 2016. Nessuna delle correzioni sopra ha funzionato per me, inclusa l'assegnazione di src a vuoto e poi di nuovo a qualche sito o l'aggiunta di qualche parametro "nome" con nome casuale, o l'aggiunta di un numero casuale alla fine dell'URL dopo l'hash, o l'assegnazione della finestra di contenuto href a src dopo aver assegnato src.

Nel mio caso, era perché stavo usando Javascript per aggiornare IFRAME e cambiavo solo l'hash nell'URL.

La soluzione alternativa nel mio caso è stata la creazione di un URL temporaneo con un meta reindirizzamento di 0 secondi a quell'altra pagina. Succede così velocemente che a malapena noto il flash dello schermo. Inoltre, ho reso il colore di sfondo della pagina provvisoria uguale a quello dell'altra pagina, quindi lo noti ancora meno.

— Volomike
fonte
0

Ho avuto questo problema anche nel 2016 con iOS Safari. Quello che sembrava funzionare per me era dare un parametro GET all'iframe src e un valore come questo

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

— Lauri Kääriäinen
fonte
-1

Hai installato Fiddler2 ?

Ti permetterà di vedere esattamente cosa viene richiesto, cosa viene rispedito, ecc. Non sembra plausibile che il browser raggiunga davvero la sua cache per URL diversi.

— Daniel Earwicker
fonte
1
Grazie per il suggerimento su Fiddler2. Ora so che il browser non memorizza nella cache il contenuto dell'iframe; sta semplicemente memorizzando nella cache l'URL iframe. Tuttavia, sono ancora perplesso e non ho idea del motivo per cui il browser ignori l'URL iframe della nuova pagina e utilizzi semplicemente il vecchio URL.
— JR.
-1

Se vuoi davvero pazzo potresti implementare il nome della pagina come un URL dinamico che si risolve sempre nella stessa pagina, piuttosto che l'opzione querystring?

Supponendo che tu sia in un ufficio, controlla se è in corso la memorizzazione nella cache a livello di rete. Credimi, è una possibilità. I tuoi addetti IT saranno in grado di dirti se esiste un'infrastruttura di rete attorno al caching HTTP, anche se poiché ciò accade solo per l'iframe è improbabile.

— Chris Webb
fonte
-2

Hai provato ad aggiungere le varie opzioni di intestazione HTTP per no-cache alla pagina iframe?

— Chris Webb
fonte
Sì. Ho provato le direttive senza cache sia nelle intestazioni HTTP che nei metatag su ogni pagina.
— JR.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.