¿Cuál es la mejor manera de lidiar con el caché y el botón de retroceso del navegador?

Question

¿Cuál es la mejor forma de manejar a un usuario que vuelve a una página que tenía elementos en caché en una aplicación asp.net? ¿Hay una buena manera de capturar el botón Atrás (evento?) Y manejar el caché de esa manera?

Answer 1

Usted puede intentar usar la HttpResponse.Cache property si eso ayuda:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60)); 
Response.Cache.SetCacheability(HttpCacheability.Public); 
Response.Cache.SetValidUntilExpires(false); 
Response.Cache.VaryByParams["Category"] = true; 

if (Response.Cache.VaryByParams["Category"]) 
{ 
    //... 
} 

O podría podría bloquear el almacenamiento en caché de la página en conjunto con HttpResponse.CacheControl, pero ha sido desaprobado en favor de la propiedad de caché anterior:

Response.CacheControl = "No-Cache"; 

Editar: realmente go nuts y O usted podría hacer todo a mano:

Response.ClearHeaders(); 
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1 
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.1 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); // HTTP 1.1 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.1 

Answer 2

La mejor manera de manejarlo es probablemente colocar una directiva de no-caché en sus páginas ASP.NET (o una página maestra si está usando una). No creo que haya una forma de tratar esto directamente en su código ASP.NET (ya que la decisión de caché está ocurriendo en el cliente).

En cuanto a MVC, no sé cómo lo lograría (suponiendo que sea diferente de ASP.NET basado en formularios Web); No lo he usado

Answer 3

Por lo que yo sé (o por lo menos han leído) es su mejor esfuerzo para tratar de no trabajar en respuesta a eventos de usuario, sino más bien pensar "en la página" ..

Arquitecto su aplicación por lo que doesn No importa si se presiona el botón Atrás. Simplemente lo tratará. Esto puede significar un poco de trabajo adicional desde el punto de vista del desarrollo, pero en general hará que la aplicación sea mucho más robusta.

Ie si el paso 3 realiza algunos cambios de datos, el usuario hace clic atrás (en el paso 2) y vuelve a hacer clic, luego la aplicación verifica si se han realizado los cambios ... O, idealmente, no hace ningún cambio duro cambios hasta que el usuario haga clic en "Aceptar" al final ... De esta forma, todos los cambios se almacenan y puede volver a llenar el formulario en función de los valores ingresados ​​previamente en la carga, todas y cada una de las veces ..

Espero que tenga sentido:)

Answer 4

RFC 2616 §13.13 dice que Historia y Cache son cosas diferentes. No debería haber absolutamente ninguna forma de que la memoria caché afecte el botón Atrás.

Si cualquier combinación de encabezados HTTP afecta al botón Atrás, es un error en el navegador ... con una excepción.

En HTTP S navegadores interpretan Cache-control: must-revalidate como petición para refrescar las páginas cuando se utiliza el botón Atrás (Mozilla llama "modo de banco tonto"). Esto no es compatible con HTTP simple.

Answer 5

El siguiente código trabajó para mí en IE9 +, FF21 y reciente Chrome:

Response.Cache.SetCacheability(HttpCacheability.NoCache | HttpCacheability.Private); 
Response.Cache.AppendCacheExtension("must-revalidate"); 
Response.Cache.AppendCacheExtension("max-age=0"); 
Response.Cache.SetNoStore(); 

Puede colocar esto en Page_Load() controlador de eventos en el MasterPage para que cada página de su aplicación requiere una ida y vuelta a la servidor al presionar el botón Atrás.