actualización duro y almacenamiento en caché de XMLHttpRequest en Internet Explorer/Firefox

Question

me hacen una petición Ajax en el que me puse la cacheability respuesta y encabezados últimos modificados:

if (!String.IsNullOrEmpty(HttpContext.Current.Request.Headers["If-Modified-Since"])) 
{ 
    HttpContext.Current.Response.StatusCode = 304; 
    HttpContext.Current.Response.StatusDescription = "Not Modified"; 
    return null; 
} 
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.Public); 
HttpContext.Current.Response.Cache.SetLastModified(DateTime.UtcNow); 

Esto funciona como se esperaba. La primera vez que hago la solicitud de Ajax, recibo 200 OK. La segunda vez que obtengo 304 Not Modified.

Cuando duro la actualización en Chrome (Ctrl + F5), obtengo 200 OK - ¡fantástico!

Cuando realizo una actualización en Internet Explorer/Firefox, obtengo 304 Not Modified. Sin embargo, cualquier otro recurso (JS/CSS/HTML/PNG) devuelve 200 OK.

La razón es porque el encabezado "If-Not-Modified" se envía para XMLHttpRequest, independientemente de la actualización estricta en esos navegadores. Creo que Steve Souders lo documenta here.

He intentado configurar un ETag y acondicionamiento en "If-None-Match" en vano (se mencionó en los comentarios en la página de Steve Souders).

¿Alguien tiene gemas de sabiduría aquí?

Gracias, Ben

actualización

pude comprobar el "-Desde If-Modified" en contra de una fecha de la última modificación almacenado. Sin embargo, es de esperar que esta pregunta ayude a otros usuarios de SO que encuentran que el encabezado no se establece correctamente.

Actualización 2

Mientras que la solicitud se envía con el "If-Modified-Since" de cabecera cada vez. Internet Explorer ni siquiera realizará la solicitud si no se establece un vencimiento o se establece en una fecha futura. ¡Inútil!

Actualización 3

Esto bien podría ser un blog en vivo ahora. Internet Explorer no se molesta en realizar la segunda solicitud cuando localhost. Usar una IP real o el loopback funcionará.

Answer 1

Antes de IE10, IE no aplica los indicadores de actualización (consulte http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx) a las solicitudes que no se realizan como parte de la carga del documento.

Si lo desea, puede ajustar la URL de destino para que contenga un nonce para evitar que la copia en caché satisfaga una solicitud futura. Alternativamente, puede enviar max-age = 0 para obligar a IE a revalidar condicionalmente el recurso antes de cada reutilización.

cuanto a por qué el navegador vuelve a utilizar un recurso en caché que no especificó toda la vida, por favor ver http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

Answer 2

La solución me encontré con un control constante fue la gestión de las cabeceras de caché para todos los tipos de peticiones.

Por lo tanto, forcé las solicitudes estándar al igual que XMLHttpRequests, que indicaba a IE que utilizara la siguiente política de caché: Cache-Control: private, max-age = 0.

Por alguna razón, IE no respetaba los encabezados de varios tipos de solicitudes. Por ejemplo, mi política de caché para las solicitudes estándar predeterminadas para el navegador y para XMLHttpRequests, se estableció en la política de control antes mencionada. Sin embargo, realizar una solicitud a algo como/url como solicitud de obtención estándar, rinde el resultado correctamente. Desafortunadamente, al hacer la misma solicitud a/url como XMLHttpRequest, ni siquiera golpeaba el servidor porque la solicitud get se almacenaba en caché y XMLHttpRequest estaba presionando la misma URL.

Así que, o forzar a su política de caché en todos los frentes o asegurarse de que está utilizando diferentes puntos de acceso (URI) para sus tipos de peticiones. Mi solución fue la primera.