2009-12-22 7 views
6

Pregunta de dos partes (las partes están estrechamente relacionadas): con la política ETAG OOTB predeterminada que emplea IIS7, ¿por qué no vemos la interacción If-None-Match/304 como navegamos por las páginas?ETags, IIS7, Política de caché del kernel (enableKernelCache)

Los encabezados devueltos para una solicitud de vacío-cache, por ejemplo, son:

Content-Type image/png 
Last-Modified Thu, 03 Dec 2009 15:51:56 GMT 
Accept-Ranges bytes 
Etag "a8a0628a3074ca1:0" 
Server Microsoft-IIS/7.0 
X-Powered-By ASP.NET 
Date Tue, 22 Dec 2009 19:47:36 GMT 
Content-Length 1780 

... y sin embargo, los accesos posteriores a la página no generan un 304 ida y vuelta para la imagen?

Además, el valor predeterminado applicationHost archivo para IIS7 tiene los siguientes (1):

<caching enabled="true" enableKernelCache="true"> 
    </caching> 

¿Tiene enableKernelCache = 'verdadero' extenderse a todos los archivos estáticos, liberándole de la necesidad de registrar extensiones explícitamente conceder CacheUntilChange como la política del núcleo (2):

<caching> 
    <profiles> 
    <add extension=".gif" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    <add extension=".png" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    <add extension=".js" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    <add extension=".css" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    <add extension=".jpg" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    <add extension=".jpeg" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" /> 
    </profiles> 
</caching> 

(1)% SystemRoot% \ System32 \ inet srv \ config \ applicationHost.config

(2) http://labs.episerver.com/en/Blogs/Per/Archive/2009/3/Configuring-cache-expiration-on-IIS-7/

Respuesta

4

El manejo de ETags y el asociado If-None-Match/Si-Modified-Since es algo dependiente navegador. Puede probar algunos navegadores diferentes y ver qué ocurre; en general, si no establece un tiempo de caducidad explícito, esperaría ver los 304, como dijo.

Para el almacenamiento en memoria caché del kernel, está habilitado para archivos estáticos de forma predeterminada. Para ayudar a ver lo que está pasando, he encontrado que es útil para ejecutar el siguiente comando:

netsh http show cachestate 

que mostrará información sobre los archivos que se encuentran actualmente en la memoria caché.

Tenga en cuenta que los archivos normalmente se deben referenciar un par de veces dentro de una ventana de tiempo determinada antes de que el núcleo los guarde en caché.

+0

Gracias, Rick; He probado tanto IE8 como FF 3.5 y encuentro este comportamiento un poco extraño, ¿está documentado en alguna parte? IIS7 (OOTB) no emite encabezados de caducidad, solo ETag; y sin embargo, las solicitudes posteriores a la página no generan 304 para estos objetos? – Nariman

+0

La única documentación que conozco es la especificación HTTP. Me pregunto si está viendo una optimización por sesión. ¿Has intentado salir del navegador (todas las ventanas), reiniciar y ver si eso da como resultado 304s? ¿Hay alguna página pública que pueda ver que muestre el comportamiento que describes? – RickNZ

+0

Dado que las respuestas originales no tienen un encabezado de control de caché, el navegador es (algo) libre de implementar su propia política con respecto al almacenamiento en caché. En este caso, elige almacenar en caché las imágenes durante la duración de la sesión. Si cierra la pestaña en IE8 con su sitio, y luego abre una nueva pestaña y vuelve a la misma página, verá un montón de solicitudes IMS/INM y 304 respuestas para todas las imágenes. – RickNZ

Cuestiones relacionadas