Intercettare l'utilizzo del tasto F5 del browser

In una applicazione ASP.NET supponiamo di avere una semplice pagina aspx contenente un pulsante, ovvero un web control Button. Cosa succede quando, dopo aver premuto il pulsante, chiediamo un Refresh della pagina (tasto F5 in Internet Explorer)?

Innanzi tutto ricordiamo che un Button viene reso sul client come un elemento HTML INPUT avente type=submit, la cui pressione da parte dell’utente provoca l'invio del form HTML alla pagina indicata dall’attributo action; nel caso di un WebForm l'attributo action indica la pagina aspx stessa. Inoltre osserviamo che in Internet Explorer il Refresh effettua la ripetizione esatta dell'ultima richiesta HTTP inoltrata dal browser per caricare il documento principale nella finestra corrente (anche Opera e Netscape si comportano allo stesso modo). Premesso ciò, vediamo i due casi che possono presentarsi.

1. Se carichiamo la pagina e poi ne chiediamo subito il Refresh, la richiesta HTTP ripetuta dal browser ha method=GET, così la pagina viene richiesta nuovamente con la modalità IsPostBack=false; questo non dovrebbe creare problemi all’applicazione, perché ciò che arriva al server web è una richiesta uguale alla richiesta iniziale della pagina.

2. Se invece carichiamo la pagina, facciamo clic sul pulsante, e poi ne chiediamo il Refresh, la richiesta HTTP ripetuta dal browser ha method=POST perché la pressione del pulsante aveva provocato il submit del form HTML. Poiché viene ripetuto il submit del form al server web, l'effetto del Refresh è di ricaricare la pagina con la modalità IsPostBack=true, e di ripetere l'evento Click del Button. Ciò potrebbe creare problemi all'applicazione, perché dopo aver trattato l'evento una prima volta, per esempio per eliminare un record da una tabella di database, la ripetizione della stessa operazione potrebbe non avere più significato. Inoltre osserviamo che, in particolare, il valore del campo nascosto __VIEWSTATE inviato al server web non è quello contenuto nel form HTML visualizzato nel browser, ma quello allegato alla precedente richiesta HTTP.

Chiarito quale può essere il problema, rimane da capire se e come possiamo risolverlo, o meglio ancora prevenirlo. Ebbene, il meccanismo di intercettazione dei tasti BACK/FORWARD del browser (già pubblicato qui) risolve anche questo caso, perché quando il browser ripete il post del form, trasmette nel ViewState un valore di controllo LastRequestTime non più aggiornato, cioè precedente a quello salvato in Session, e quindi la verifica del valore di controllo permette di rilevare l'azione dell'utente. L'applicazione allora può reagire intraprendendo un'azione correttiva specifica, comunque nella maggior parte dei casi risulta appropriato reindirizzare di nuovo il browser alla pagina stessa (mediante Response.Redirect), in modo che la pagina venga ricaricata daccapo in modalità IsPostBack=false.