¿Por qué Chrome usa el caché del cliente de manera diferente en estos dos escenarios?

Question

Estoy trabajando en una pequeña aplicación de una sola página usando HTML5. Una característica es mostrar los documentos PDF incrustados en la página, que documentos se pueden seleccionar de una lista.

NOw Estoy tratando de hacer que Chrome (al principio, y luego todos los otros navegadores modernos) usen la memoria caché del cliente local para cumplir con la simple solicitud GET para documentos PDF sin pasar por el servidor (que no sea la primera vez del curso)) Hago que el archivo PDF se solicite configurando la propiedad "datos" en un elemento <object> en HTML.

He encontrado un working example for XMLHttpRequest (no <object>). Si utiliza las herramientas para desarrolladores de Chrome (pestaña Red) se puede ver que la primera solicitud va al servidor, y da lugar a una respuesta con estos encabezados:

Cache-Control:public,Public 
Content-Encoding:gzip 
Content-Length:130 
Content-Type:text/plain; charset=utf-8 
Date:Tue, 03 Jul 2012 20:34:15 GMT 
Expires:Tue, 03 Jul 2012 20:35:15 GMT 
Last-Modified:Tue, 03 Jul 2012 20:34:15 GMT 
Server:Microsoft-IIS/7.5 
Vary:Accept-Encoding 

La segunda petición se sirve de la caché local sin ningún tipo de servidor ida y vuelta, que es lo que quiero.

De vuelta en mi propia aplicación, que luego se usa ASP-NET MVC 4 y ajuste

[OutputCache(Duration=60)] 

en mi controlador. La primera solicitud a este controlador - con URL http://localhost:63035/?doi=10.1155/2007/98732 resultados en las siguientes encabezados:

Cache-Control:public, max-age=60, s-maxage=0 
Content-Length:238727 
Content-Type:application/pdf 
Date:Tue, 03 Jul 2012 20:45:08 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

la segunda petición resultados en otro ida y vuelta al servidor, con una respuesta mucho más rápido (lo que sugiere el almacenamiento en caché del lado del servidor?) Pero devuelve 200 OK y estos encabezados:

Cache-Control:public, max-age=53, s-maxage=0 
Content-Length:238727 
Content-Type:application/pdf 
Date:Tue, 03 Jul 2012 20:45:13 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

La tercera solicitud de los mismos resultados de URL en otra ida y vuelta y una respuesta 304 con estos encabezados:

Cache-Control:public, max-age=33, s-maxage=0 
Date:Tue, 03 Jul 2012 20:45:33 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

Mi pregunta es, ¿cómo debo configurar el atributo OutputCache para obtener el comportamiento deseado (es decir Solicitudes PDF completadas desde el caché del cliente, dentro de X segundos de la solicitud inicial)?

¿O no estoy haciendo las cosas bien cuando hago que se visualice el PDF configurando la propiedad "data" en un elemento <object>?

Answer 1

Ha intentado establecer la propiedad Localización de la OutputCache a "Cliente"

[OutputCache(Duration=60, Location = OutputCacheLocation.Client)] 

Por defecto, la propiedad de ubicación se establece en "cualquiera" que podría significar que la respuesta se almacena en caché en el cliente, en una proxy, o en el servidor.

más en MSDN OutputCacheLocation

Answer 2

clientes nunca son obligado a caché. Cada navegador es libre de usar su propia heurística para decidir si vale la caché de un objeto. Después de todo, cualquier uso de la memoria caché "compite" con otros usos de la memoria caché.

El almacenamiento en caché no está diseñado para garantizar una respuesta rápida; está diseñado para, en promedio, aumentar la probabilidad de que recursos de uso frecuente que no cambian ya estén allí.Lo que estás tratando de hacer, no es con qué cachés están diseñados para ayudar.

Según los resultados que informa, la versión de Chrome que estaba utilizando en 2012 decidió que no tenía sentido almacenar en caché un objeto que caducaría en 60 segundos y solo se lo había solicitado una vez. Entonces tiró la primera copia, después de usarla. Luego, solicitó una segunda vez y comenzó a darle a esta URL un poco más de prioridad: debe haber recordado las URL recientes y observó que se trataba de una segunda solicitud; mantuvo la copia en caché, pero cuando llegó la tercera solicitud, , preguntó al servidor para verificar que aún era válido (presumiblemente porque el tiempo de caducidad estaba a solo unos segundos de distancia). El servidor dijo "304 - no modificado - use la copia que guardó en la memoria caché". NO envió el pdf nuevamente.

En mi humilde opinión, ese fue el comportamiento razonable de caché, para un objeto que caducará pronto.

---

Si se desea aumentar la probabilidad de que el PDF se quedará más tiempo, a continuación, dar un tiempo de caducidad más tarde, pero dicen que se debe consultar con el servidor para ver si todavía es válida.

Si utiliza el encabezado HTTP Cache-Control, esto podría ser: private, max-age: 3600, must-revalidate. Con esto, debería ver un viaje de ida y vuelta al servidor, que dará una respuesta de 304 siempre que la página sea válida. Esta debería ser una respuesta rápida, ya que no se envía datos - se usa la versión en caché del navegador.

private es opcional - no está relacionado con este comportamiento de almacenamiento en caché - Asumo que este PDF volátil es, solo tiene sentido para el usuario dado y/o no debe permanecer por mucho tiempo, en alguna ubicación compartida.

---

Si realmente necesita el rendimiento de no hablar con el servidor en absoluto, a continuación, que no escribe Javascript para ocultar/mostrar el elemento DOM sostiene que PDF, en lugar de dejarlo caer, y la necesidad de preguntar por ella de nuevo.

Su código de JavaScript para la página es el único lugar que "entiende" que realmente desea que ese PDF se quede, incluso si actualmente no se lo está mostrando al usuario.