2010-02-01 15 views
16

Si consideri lo scenario:Cosa succede quando premo il pulsante BACK del browser?

  1. ho visitato una pagina di un sito web costruito utilizzando ASP.NET. La pagina è una semplice pagina di aspx contenente i controlli del server ASP.NET.

  2. Ho fatto clic su un collegamento che porta a un'altra pagina sullo stesso sito Web.

  3. Ho fatto clic sul pulsante INDIETRO del browser.

DOMANDA: Cosa succede in termini di ciclo di vita della pagina? Si verificano tutti gli eventi o il browser visualizza solo la versione cache della pagina senza effettuare alcuna richiesta?

risposta

15

Penso che la risposta migliore sia: dipende dal browser, soprattutto dopo un post/postback.

I browser più vecchi popolavano una finestra di dialogo di conferma con l'effetto di "la pagina contiene i dati POST che verranno nuovamente inviati" e si può procedere (reinviare) o annullare. Poiché tutto ciò che accade in ASP.NET WebForms fa parte dell'elemento FORM (ViewState, eventi, ecc.), Ciò causerebbe la ripetizione dell'intero ciclo di vita.

Ovviamente questo non ha causato problemi con invii duplicati, quindi molti siti hanno dovuto escogitare soluzioni alternative per il problema del dupe e oggi la maggior parte dei browser recupera invece la pagina dalla cache.

... Questo è a meno che non sovrascrive le intestazioni di controllo della cache e impone al browser di non memorizzare la pagina nella cache. Ovviamente, in quel caso, non può essere recuperato dalla cache, quindi di solito finirà per essere ripresentato. Ma, di nuovo, dipende dal browser - per esempio, alcuni browser non permetteranno la nuova presentazione su SSL, quindi se questo è il protocollo in uso allora l'utente vedrà solo un messaggio che dice che la pagina è scaduta/non può essere mostrato.

Vieni a pensarci, probabilmente una risposta ancora migliore è: come progettista di un sito, non si può realmente dipendere da alcun comportamento specifico dal browser dell'utente quando si fa clic sul pulsante Indietro. Se una presentazione duplicata potrebbe avere effetti collaterali negativi (ad esempio, l'addebito di una carta di credito due volte), allora è necessario adottare misure adeguate per evitare che ciò accada. È comunque una buona pratica poiché è completamente possibile per un utente fare semplicemente doppio clic sul pulsante "invia" per sbaglio.

+0

Sono d'accordo con la risposta di Aaronaught. Non proverei a scrivere alcun codice che presuppone che il pulsante "indietro" si comporterà in un certo modo su tutti i browser. – jessegavin

+0

Penso che tu abbia considerato uno scenario diverso di post-backing della stessa pagina usando un controllo e poi premendo il pulsante INDIETRO ... Ho ragione? – Manish

+0

@Manish: ciò che conta non è necessariamente se la pagina * present * dell'utente abbia i dati 'POST', ma se la * precedente * pagina (quella a cui il pulsante Indietro li porterà) abbia i dati' POST' . Ciò include entrambi gli scenari: il ritorno da un postback e il ritorno da una nuova pagina quando la pagina precedente aveva un postback (o semplicemente 'POST'). – Aaronaught

0

di solito dovrebbe avvenire tutti gli eventi, ma se si dispone di un browser uber di quello che potrebbe accadere per visualizzare una pagina in cache solo si può mettere un punto di interruzione nella vostra pagina di carico e vedere se sta andando a verificarsi

0

La pagina verrà visualizzata dalla cache.

+0

Quindi, se ho Response.Cache.SetCacheability (HttpCacheability.NoCache) insieme, sarebbe colpire Indietro sì che il browser per emettere un Get richiesta per la pagina provious, o forse anche un postback se quella era l'ultima azione dell'utente? – AaronLS

+0

sì sarebbe postback se si dispone di Response.Cache.SetCacheability (NoCache) impostato, ma per alcune pagine vedrai lo stesso contenuto. Provare a utilizzare Response.Cache.SetCacheability (HttpCacheability.NoCache); Response.Cache.SetExpires (DateTime.Now-new TimeSpan (1,0,0)); Response.Cache.SetLastModified (DateTime.Now); Response.Cache.SetAllowResponseInBrowserHistory (false); – Ravia

+0

Penso che otterresti un avviso "Pagina scaduta" invece della pagina, ma penso che dipenda ancora dal browser. – Codesleuth

1

abbiamo anche provato

Response.ExpiresAbsolute = DateTime.Parse("1/1/1980"); 
Response.AddHeader("cache-control", "no-store, must-revalidate, private"); 
Response.AddHeader("Pragma", "no-cache"); 

per risolvere questo tipo di problema

Problemi correlati