Newsgroup: it.comp.java
Titolo: Impedire il caching delle pagine e bloccare i tasti back / forward

Ebbene si, alla fine e' capitato pure a noi! Inizialmente non credevo ci potesse dare
fastidio, ma invece ecco la famigerata accoppiata tasto back + cache del browser che
arriva a rompere nella nostra applicazione web.
Allora, come risolvere il problema? Abbiamo cercato un po' in giro e abbiamo trovato
alcune soluzioni che purtroppo su Internet Exploder sembrano non funzionare. In questo
post cerchiamo di fare un riassunto delle possibilita' che ci sono, e chiedendo a tutti un
consiglio.
1) Impostare gli header 
Okay, il metodo classico che io conoscevo e' quello di impostare gli header nella risposta
HTTP in questo modo:
    response.setHeader    ("Pragma", "no-cache");
    response.setHeader    ("Cache-Control", "no-cache");
    response.setDateHeader("Expires", 0);
Troppo facile: funziona con Netscape ma non con IE 5.5. Quando si preme il tasto back o
forward non avviene alcuna richiesta al server ma la pagina viene pescata dalla cache
2) La soluzione (1) + meta nella pagina
Okay, allora ho provato ad inserire anche i relativi meta-tag nella pagina:
    writer.println("<HEAD>");
    writer.println("<meta http-equiv=\"Expires\" content=\"0\">");
    writer.println("<meta http-equiv=\"Pragma\" content=\"no-cache\">");
    writer.println("<meta http-equiv=\"Cache-Control\" content=\"no-cache\">");
    writer.println("</HEAD>");
Come prima. Nestcape ok, IE 5.5 ko!
3) La soluzione (2) + il finto parametro 
Allora in aggiunta a (2) ho tentato un ulteriore trucco: aggiungere un finto parametro
(random) alla pagina in modo che fosse sempre diversa. 
Come prima. Nestcape ok, IE 5.5 ko!
4) La soluzione javascript
Smanettando con javascript pero' sono riuscito a farlo funzionare. Quando si usa il metodo
location.replace() viene sovrascritta la posizione corrente nell'history, e non se ne crea
una nuova. E' quindi sufficiente cambiare i link in questo modo:
    <a href=javascript:onclick=location.replace("./ServletPagina2")>Pagina 2</a>
Tutto funziona egregiamente, anzi, il bello e' che non si illuminano neanche i bottoni
back e forward... sempre pero' se l'utente ha attivo il supporto javascript!
C'e' pero' un drawback: funziona solo con la GET, quando devi fare una POST o la trasformi
al volo in una GET oppure ciccia. Al limite si puo' provare facendo una sendRedirect() al
ritorno della form, questo devo ancora verificarlo.
5) La soluzione naive
Beh, ovviamente e' possibile aprire una finestra (sempre usando javascript) priva dei
controlli back e forward, disabilitando contemporaneamente anche il tasto DX del mouse. Ma
questa e' la soluzione che mi piace meno.
Non l'ho provata, ma dovrebbe funzionare.
6) La soluzione cookie
E' possibile usare un cookie che viene incrementato dal server a ogni download e che viene
testato dai vostri controlli: certo pero' che e' necessario un pesante codice javascript
di controllo ad esempio nella onLoad() e che interagisca in qualche modo con l'utente 
Non l'ho provata, ma dovrebbe funzionare.
7) La soluzione onUnload()
Altra possibilita, nell'onUnload() impostarsi un flag (sempre javascript) che non consente
piu' di avere accesso a quella pagina. Uhm... molto brutta, e si presta a un po' troppi
casini per i miei gusti.
Non l'ho provata, ma dovrebbe funzionare.
Okay, eccomi alla fine della piaga. Se qualcuno ha qualche soluzione funzionante, posti
sul NG: a me interesserebbe in particolare una soluzione che non richieda il supporto
javascript, ma qualunque ulteriore soluzione e' ben accetta. A questo punto, quando avremo
definito l'insieme delle soluzioni possibili (oltre a queste) non restera' che mettere un
nuovo punto nelle FAQ. Anche se leggermente OT, c'e' da dire che 'sto problema rompe
parecchio: varrebbe la pena di terminarlo per sempre! Aspettiamo lumi!
FYI, comunque, per ora ci stiamo per indirizzare verso una combinazione di (4) e (5)
Ciao,
    Bruno.
P.S.
Qualche ulteriore info per chi si vuole documentare:
- Caching tutorial
 
http://www.mnot.net/cache_docs/
- HTTP/1.1 (RFC 2616)
 
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2616.html
- La soluzione 1 come la postai nel 2000 (e cacchio, allora funzionava!)
http://groups.google.com/groups?hl=en&lr=&ie=UTF8&oe=UTF8&selm=8n18uq%24pel%241%40nnrp1.deja.com
- Google a manetta :-)	
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola

     response.setDateHeader("Expires", 0);
Bruno, potresti provare con
    response.setHeader("Pragma", "No-cache");
    response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate, max_age=0");
    response.setHeader("Expires","0");
e farmi sapere se funziona?
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

Prova con Expires = -1

 Prova con Expires = -1
-1, come 0, viene considerato 'nel passato'. La RFC 2616 parla con
speciale enfasi di "0", ma qualsiasi valore di data illegale, anche -1,
dovrebbe far considerare il documento scaduto. Bisogna vedere come
quella ciofeca di IE si comporta con gli standard... chissà se Bruno nel
frattempo ha risolto?



Sorry per il delay ma ero a Milano (e purtroppo non alla Java Conference).
No, non funge :-( (in entrambi i modi, sia con 0 che con -1)
Alla pressione del tasto back del browser IE si ripiglia la pagina che ha nella cache e
non caga assolutamente il server.
Sigh! Altri suggerimenti?
Ciao,
    Bruno.
