htaccess control cache age iis google-chrome cache-control content-expiration

iis - cache - ¿Está Chrome ignorando el control de caché: max-age?



cache-control html5 (5)

Fondo:

  • IIS 7
  • Aplicación web AspNet 3.5

Las herramientas de desarrollo de Chrome listan 98 solicitudes para la página de inicio de la aplicación web (aspx + js + css + images). En las siguientes solicitudes, el código de estado es 200 para archivos css / images. Sin información de caché, el navegador pregunta al servidor cada vez que se debe actualizar el archivo. DE ACUERDO.

En IIS 7 configuro el encabezado HTTP para el control de caché, configurado en 6 horas para la carpeta "recursos". En Chrome, usando las herramientas de desarrollo, veo que el encabezado está bien configurado en respuesta:

Cache-Control: max-age=21600

Pero todavía recibo 98 solicitudes ... Pensé que el navegador no debería solicitar un recurso si no se alcanza su fecha de caducidad, y esperaba el número de solicitudes para dejar ...

Chrome parece ignorar la configuración de Cache-Control si estás recargando en la misma pestaña. Si copia la URL en una nueva pestaña y la carga allí, Chrome respetará las etiquetas de control de caché y reutilizará los contenidos de la memoria caché.

Como ejemplo, tuve esta aplicación Ruby Sinatra:

#!/usr/bin/env ruby require ''sinatra'' before do content_type :txt end get ''/'' do headers "Cache-Control" => "public, must-revalidate, max-age=3600", "Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s "This page rendered at #{Time.now}." end

Cuando lo recargué continuamente en la misma pestaña de Chrome, se mostraba la nueva hora.

This page rendered at 2014-10-08 13:36:46 -0400. This page rendered at 2014-10-08 13:36:48 -0400.

Los encabezados se veía así:

< HTTP/1.1 200 OK < Content-Type: text/plain;charset=utf-8 < Cache-Control: public, must-revalidate, max-age=3600 < Expires: 2014-10-08 13:36:46 -0400 < Content-Length: 48 < X-Content-Type-Options: nosniff < Connection: keep-alive * Server thin is not blacklisted < Server: thin

Sin embargo, al acceder a la misma URL, http://localhost:4567/ de múltiples pestañas nuevas reciclaría el resultado anterior de la memoria caché.

Después de hacer algunas pruebas con Cache-Control:max-age=xxx :

  • Al presionar el botón de recarga: cabecera ignorada
  • Ingresando la misma url en cualquier pestaña (actual o no): honrado
  • Usando JS ( window.location.reload() ): ignorado
  • El uso de herramientas de desarrollo (sin activar la caché) o de incógnito no afecta

Entonces, la mejor opción mientras se desarrolla es colocar el cursor en el cuadro multifunción y presionar el botón enter en lugar de refresh.

Nota : si hace clic con el botón derecho en el ícono de actualización, se mostrarán las opciones de actualización (Normal, Difícil, Vacío). Increíblemente, ninguno de estos afecta en estos encabezados.

Entiendo. Google Chrome ignora el encabezado Cache-Control o Expires si realiza una solicitud inmediatamente después de otra solicitud al mismo URI en la misma pestaña (haciendo clic en el botón Actualizar, presionando la tecla F5 o presionando Comando + R ). Probablemente tiene un algoritmo para adivinar qué es lo que el usuario realmente quiere hacer.

Una forma de probar el encabezado Cache-Control es devolver un documento HTML con un enlace a sí mismo. Al hacer clic en el enlace, Chrome sirve el documento de la memoria caché. Por ejemplo, nombre el siguiente documento self.html :

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Test Page</title> </head> <body> <p> <a href="self.html">Link to the same page.</a> If correctly cached, a request should not be made when clicking the link. </p> </body> </html>

Otra opción es copiar la URL y pegarla en la misma pestaña u otra pestaña.

ACTUALIZACIÓN : en una publicación de Chrome publicada el 26 de enero de 2017 , se describe cuál fue el comportamiento anterior y cómo está cambiando haciendo solo la revalidación del recurso principal , pero no de los recursos secundarios :

Los usuarios suelen volver a cargar, ya sea porque una página está rota o porque el contenido parece obsoleto. El comportamiento de recarga existente generalmente soluciona las páginas rotas, pero el contenido obsoleto es abordado ineficazmente por una recarga regular, especialmente en dispositivos móviles. Esta característica se diseñó originalmente en momentos en que las páginas rotas eran bastante comunes, por lo que era razonable abordar ambos casos de uso a la vez. Sin embargo, esta preocupación original ahora se ha vuelto menos relevante a medida que la calidad de las páginas web ha aumentado. Para mejorar el uso de contenido obsoleto, Chrome ahora tiene un comportamiento de recarga simplificado para validar solo el recurso principal y continuar con una carga de página regular. Este nuevo comportamiento maximiza la reutilización de los recursos almacenados en caché y reduce la latencia, el consumo de energía y el uso de datos.

En una publicación de Facebook también publicada el 26 de enero de 2017 , se menciona que encontraron una pieza de código donde Chrome invalidó todos los recursos almacenados en caché después de una solicitud POST:

descubrimos que Chrome revalidaría todos los recursos en las páginas que se cargaron para realizar una solicitud POST. El equipo de Chrome nos dijo que la razón para esto era que las solicitudes POST tienden a ser páginas que realizan un cambio, como hacer una compra o enviar un correo electrónico, y que el usuario desearía tener la página más actualizada.

Parece que este ya no es el caso.

Finalmente, se describe que Firefox está introduciendo Cache-Control: immutable para detener por completo la revalidación de recursos:

Firefox implementó una propuesta de uno de nuestros ingenieros para agregar un nuevo encabezado de control de caché para algunos recursos con el fin de decirle al navegador que este recurso nunca debe ser revalidado. La idea detrás de este encabezado es que es una promesa adicional del desarrollador para el navegador que este recurso nunca cambie durante su vida útil máxima. Firefox eligió implementar esta directiva en forma de un control de caché: encabezado inmutable.

Espero que esto ayude a desenredar los misterios de recarga.

Otro consejo:

No olvide verificar el encabezado "Fecha": si el servidor tiene una fecha / hora incorrecta (o se encuentra en otra zona horaria), Chrome seguirá solicitando recursos una y otra vez.

Si Chrome Developer Tools está abierto (F12), Chrome generalmente desactiva el almacenamiento en caché.

Se puede controlar en la configuración de herramientas del desarrollador: el icono de engranaje a la derecha de la barra superior de herramientas de desarrollo.