Impedire il salvataggio nella cache del browser
Lunedì 20 Aprile 2009 - 08:29
di Cesare Lamanna
Una delle cose che più mi sono sentito chiedere da amici e conoscenti alle prese con siti e blog amatoriali è: come si può impedire il salvataggio dei file nella cache del browser?
Senza mai chiedere il motivo di simili richieste, ho fatto ricorso alle mie conoscenze e a Google per suggerire di volta in volta le tecniche più adatte. Da quella basata sul puro e semplice HTML
<meta http-equiv="cache-control" content="no-cache"> <meta http-equiv=”expires” content=”0″> <meta http-equiv=”pragma” content=”no-cache”>
a quelle più semplici per ASP o PHP. E ora vedo che si può fare anche con jQuery e Javascript.
In verità, nelle mie investigazioni su Google, ho anche spesso verificato come tutto ci sia meno che accordo unanime sull’efficacia reale di ciascun metodo. Per cui vi chiedo: esiste o non esiste un metodo più valido degli altri? E se sì, qual è?
Così la prossima volta che me lo chiedono do direttamente l’URL di questo post ;).
Categoria: Scripting | Permalink
Commenti
1
Ricorrere al js per impedire il salvataggio nella cache del browser, anche se poco invasivo, non la trovo una scelta ottimale. Personalmente evito quanto più possibile, se ci sono altre soluzioni, di usare codice js nelle pagine.
2
Leggendo qui (http://docs.jquery.com/Release:jQuery_1.2/Ajax) da quello che ho capito quel parametro ‘cache’ assicura solo che ciascuna richiesta GET non vada a leggere un dato eventualmente giò in cache (viene aggiunto un timestamp alla chiamata, riga 3453 del sorgente non compresso, versione 1.3.2) e non tanto la disabilitazione della cache in sé.
L’effetto che si ottiene con jQuery è differente da quello che si ottiene usando solo i metatags
# - postato da Fabrizio Calderan - 20 Aprile 2009 - 10:15
3
sicuramente edit non può non dicutere una faccenda del genere…
per una questione “scientifica” in sé…
e anche perché, è vero, viene sempre richiesta da qualcuno… e edit “fa testo”…però, su edit non si può non dire che si tratta di una richiesta “contro-natura-del-web” (del sistema server+pagine-web+browser)…
credeo di sapere il perché di molte richieste del genere…
e lo so perché ci sono passato…
spesso sono dovute alle poche competenze…qualche anno fa per permettere ai miei primissimi clienti di cambiare l’immagine di background a seconda della stagione avevo implementato una soluzione macchinosissima (in php!!) che interveniva sul css per modificare una riga però poi gli utenti si ritrovavano con il solito sfondo fino a quando non facevano F5…
giravo forum, chiedevo a destra e a manca, baravo con il cliente…ma che è normale lavorare così?!
è assurdo… qualcuno avrebbe dovuto dirmi che sbagliavo approccio… non solo soluzione, ma proprio approccio…
(perché ad esempio in altri casi paralleli avevo invece assolutamente bisogno della cache, perché ci mettevo delle immaginone di quasi un mega che solo se erano già in cache riuscivi a non far attendere l’effetto tendina del loro caricamento…)Insomma, per non farla troppo lunga:
a parte i casi (che possono sempre esistere, lo ammetto) in cui evitare la cache è davvero utile, su edit (CHE FA TESTO) non bisognerebbe discutere ANCHE della liceità di soluzioni del genere?Buona giornata a tutti
:)
4
Capisco che discutere del salvataggio nella cache del browser pone problemi “etici”.
Invece suggerisco di spostare l’attenzione a come imporre al browser di ricaricare una pagina con tutti file connessi, soprattutto le immagini.
5
@EsseZeta: hai messo in chiaro esattamente il mio pensiero, e ti ringrazio per questo. Quando dico “Senza mai chiedere il motivo di simili richieste” intendo celare con un eufemismo il mio stupore per richieste che mi sono sempre sembrate assurde e come di dici giustamente “contro-natura-del-web”. Da qui però a non a discuterne secondo me ce ne passa :) Anzi, sono proprio i commenti come i tuoi quelli utili a mettere la discussione nei binari giusti. Siamo qui per questo. Se alla fine di tutto viene fuori che è proprio sbagliato l’approccio e non la questione della soluzione, magari qualcuno si convince che è giusto così (e sai bene che i ‘qualcuno’ non sono pochi…). Magari ho sbagliato il taglio del post, ma credimi, non c’era proprio l’intenzione di promuovere certe pratiche :)
# - postato da Cesare Lamanna - 20 Aprile 2009 - 11:16
6
credimi, non c’era proprio l’intenzione di promuovere certe pratiche
spreco un commento…
ma che ti sei impazzito, a Cesare!
è chiaro che non ne avevi l’intenzione… altrimenti edit non “farebbe testo”
hi hi hi :p
7
quando si lavora in dinamico è relativamente semplice forzare che un file venga preso comunque.
basta realizzare un indice casuale e appenderlo all’url. uso questa tecnica regolarmente sia in php, javascript e actionscript.
io ve la posto, magari può tornarvi comoda.
per esempio se in php ho un css caricato dinamico
$indice=rand(1,1000);
nell’import invece penso che non serve inquanto incorpora nella pagina.
in actionscript serve quando si prende un input xml da linguaggio lato server, per evitare che venga caricata sempre il solito input.
8
scusate, ho isnerito del codice html che penso non venga visualizzato…..ma qui su edit l’html viene eseguito? :o
comunque quando si richiama il css si appende in get l’indice casuale creato
9
non ho capito perche’ state mischiando pere e cinghiali … la soluzione “Ajax” che e’ vecchia quanto quella html o server, serve ad evitare cache dei risultati su chiamate runtime per pagine dinamiche. Lo stesso url che produce XML, JSON, HTML, quello che volete, se chiamato due volte e senza metodi per ovviare caching della pagina puo’ generare lo stesso risultato anche se il server ne ha prodotto uno diverso. Quella pratica e’ quindi usata praticamente solo per Ajax, che essendo applicabile esclusivamente tramite JavaScript, non ha senso dire: io al JS non voglio fargli gestire la cache … cosa fate, spostate sul server il problema per un qualcosa che e’ gestito solo dal client? Poi ci sono casi e casi, ma al limite si fa doppio filtro (server/client) ma no che via Ajax non e’ giusto usare JavaScript per ovviare la cache … scusatemi ma senso di tanti commenti letti uguale a zero.
P.S. jQuery non ha inventato niente qui e il link con la spiegazione non e’ completo. Se c’e’ gia’ un ? in query string si agigunge & all’url per non rompere, per l’appunto la query string.
10
prima di rispondere alla domanda bisogna sapere perché.
altrimenti è come chiedere al meccanico “come posso impedire che il motore raggiunga i 10.000 giri?”
i motivi possono essere differenti, e ci sono differenti soluzioni (parziali) per ogni caso, o non soluzioni (nel senso che non conviene)
# - postato da Mik - 21 Aprile 2009 - 23:05
11
In realtà hai frainteso tutto: questi in realtà vogliono sapere come si disabilita la cache del browser ma non lato server quanto lato utente, tipo “preferenze del browser e/o di internet/disabilita cahe” (per non salvare i sitarelli poco… belli)
Perdonate l’ironia, non ho saputo trattenermi.
12
ah a aa
ha fatto la battuta! facesse ridere …DISABILITARE LA CACHE non vuol dire nulla
vuoi che la pagina faccia il refresh se uno preme il tasto back?
oppure
vuoi che la pagina non sia temporaneamente memorizzata sull’hard disk?
oppure
altro?anche se sembra la stessa cosa non lo è!
di cache non c’è solo quella su disco c’è pure quella della memoria RAM usata dal browser, e ogni browser le gestisce a suo modo (tenendo conto delle MOLTO generiche impostazioni utente e specifiche HTML e HTTP)
# - postato da Mik - 22 Aprile 2009 - 23:44
13
@Mik, che sia RAM poco conta, la relazione è in hash table, comuqnue la metti:
url richiesto ==>> pagina restituita
per l’url ci sono regole, dove una query string è parte delle regole. L’aggiunta di una nuova query string genera comunque uno nuova risposta, anche se è la stessa, quindi in qualche modo il forzare la cache via server serve relativamente se l’utente usa una nuova query string. Sunto: la pratica Ajax, solo Ajax, di aggiungere timestamp (poco serio) o Math.random() (più affidabile) o entrambi (soluzione migliore) è la più consigliata per chiamate Ajax su risultati che possono cambiare arbitrariamente …. che siano files di testo, xml, richieste php, aspx, jsp, psp, o altro.
Il punto è che prima di parlare di soluzioni, bisognerebbe capire il problema … in quanti siamo pigri qui?
14
@ andr3a
hai detto bene “prima bisognerebbe capire il problema”
il caso che tu riporti è solo uno dei tanti che tutti i “pigri” come te mettete nel calderone del “forzare la cache”, il quale in realtà include tanti problemi diversi a cui (ripeto) corrispondono varie diverse soluzioni
quella tua soluzione “universale” x esempio va bene per il conteggio delle impression su un banner, non va bene x esempio per un sito di commercio elettronico per interfacciarsi ad un gateway payment system tramite un form con un campo hidden con una one time password
l’utente inizia la procedura di pagamento poi torna indietro con il pulsante back e se il browser (in base a come interpreta intestazioni HTML HTTP e preferenze utente) prende la pagina della RAM è come se non avesse mai abbandonato la pagina, così si ritrova la vecchia url, le vecchie intestazioni HTTP incluso il vecchio referer, il vecchio html generato da javascript/ajax, e la vecchia one time password ormai inutilizzabile
# - postato da Mik - 23 Aprile 2009 - 03:07
15
Mik, quanto hai detto tu c’entra zero con la soluzione JavaScript per chiamate Ajax, quindi ben venuto tra i pigri (lavoro su tutto quello che hai detto, peccato io abbia anche controllo sulla history). Ciao