Encabezados de control de caché HTTP ideales para diferentes tipos de recursos

82

Quiero encontrar un conjunto mínimo de encabezados que funcionen con "todos" los cachés y navegadores (¡también cuando se usa HTTPS !)

En mi sitio web, tendré tres tipos de recursos:

(1) Siempre almacenable en caché (público / igual para todos los usuarios)

Ejemplo: 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( generado automáticamente por GWT )

  • A estos archivos se les asigna automáticamente un nuevo nombre cuando cambian de contenido (según el MD5).

  • Deben almacenarse en caché tanto como sea posible, incluso cuando se usa HTTPS (así que supongo que debo configurar Cache-Control: public, ¿especialmente para Firefox?)

  • No deberían exigir que el cliente realice un viaje de ida y vuelta al servidor para validar, si el contenido ha cambiado.

(2) Cambio ocasional (público / igual para todos los usuarios)

Ejemplos: index.html, mymodule.nocache.js

  • Estos archivos cambian su contenido sin cambiar la URL, cuando se implementa una nueva versión del sitio.

  • Se pueden almacenar en caché, pero probablemente necesiten un viaje de ida y vuelta para revalidarlos cada vez.

(3) Individual para cada solicitud (privado / específico del usuario)

Ejemplo: respuestas JSON

  • Estos recursos nunca deben almacenarse en caché sin cifrar en el disco bajo ninguna circunstancia. (Excepto que tal vez tenga algunas solicitudes específicas que podrían almacenarse en caché).

Tengo una idea general sobre qué encabezados probablemente usaría para cada tipo, pero siempre hay algo que podría faltar.

http caching https http-headers Chris Lercher
fuente
Gracias por sus respuestas y los comentarios y los enlaces. Todavía estoy experimentando un poco, pero creo que podré encontrar una solución.
Chris Lercher
2
Por lo general, no es posible lograr el número 3.
EricLaw
Véase también: stackoverflow.com/questions/6491789/…
Mikko Rantalainen

Respuestas:

90

Probablemente usaría estas configuraciones:

  1. Cache-Control: max-age=31556926- Las representaciones pueden almacenarse en caché mediante cualquier caché. La representación almacenada en caché debe considerarse nueva durante 1 año:

    Para marcar una respuesta como "nunca caduca", un servidor de origen envía una Expira la fecha aproximadamente un año desde que se envió la respuesta. Los servidores HTTP / 1.1 NO DEBEN enviar fechas de caducidad de más de un año en el futuro.

  2. Cache-Control: no-cache- Cualquier caché permite almacenar en caché las representaciones. Pero los cachés deben enviar la solicitud al servidor de origen para su validación antes de liberar una copia en caché.
  3. Cache-Control: no-store - Los cachés no deben almacenar en caché la representación bajo ninguna condición.

Consulte el Tutorial de almacenamiento en caché de Mark Nottingham para obtener más información.

Gumbo
fuente
1
@Gumbo: Una cosa de la que estoy bastante seguro es que necesito establecer público , cuando quiero que Firefox 3+ almacene en caché los archivos públicos en el disco mientras uso HTTPS: stackoverflow.com/questions/174348/…
Chris Lercher
2
Algunos navegadores, como IE, están empezando a tratar Cache-Control: no-cache como si no tuviera almacenamiento. Es cierto que esto no está de acuerdo con el RFC, pero se hace a sabiendas para "arreglar" el error cometido por MUCHOS de no usar caché para evitar que los datos confidenciales se almacenen sin cifrar en el disco.
AviD
1
@chris_l, me encontré con este enlace: palisade.plynt.com/issues/2008Jul/cache-control-attributes . No recuerdo cómo se comportaron las versiones anteriores, aunque creo que IE7 también lo hizo.
AviD
2
Además, Firefox ya no requiere PUBLIC en Cache-Control para almacenar en caché los recursos HTTPS. Pero su mejor apuesta en general es probar su sitio mientras observa el tráfico, por ejemplo, con Fiddler.
EricLaw
3
No se recomienda establecer un valor de control de caché de 100 años. En primer lugar, la especificación recomienda un máximo de 1 año. En segundo lugar, cualquier valor de más de 68 años da como resultado el vencimiento inmediato de IE8 e inferior: blogs.msdn.com/b/ieinternals/archive/2010/01/26/…
EricLaw
-2

Los casos uno y dos son en realidad el mismo escenario. Debe configurar Cache-Control: publicy luego generar una URL que incluya el número de compilación / versión del sitio para que tenga recursos inmutables que podrían durar para siempre. También desea configurar el Expiresencabezado un año o más en el futuro para que el cliente no necesite emitir un cheque de actualización.

Para el caso 3, puede hacer todo lo siguiente para una máxima flexibilidad: 

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"
Andrew L
fuente
Las diferentes URL para nuevas compilaciones probablemente no sean una opción: a) Esto obligaría al cliente a volver a descargar los archivos que se pueden almacenar en caché para siempre. Obtienen nombres únicos para evitar eso. b) La URL principal de mi sitio debe ser solo https://www.example.com/c) Quiero que los marcadores siempre se refieran a la versión más reciente de mi sitio (imagínese, los marcadores de una pregunta de stackoverflow contendrían el número de compilación del sitio).
Chris Lercher
Hola Chris: Este enfoque se usa generalmente para recursos CSS y JS en lugar de documentos. Estoy de acuerdo en que no es aplicable para identificadores de documentos, en cuyo caso simplemente debe configurar el control de caché público, Última modificación y etag en los encabezados, lo que provocará una verificación de actualización cada vez y solo se devolverá un 304 si no hay cambios desde la última descarga. Alternativamente, puede descargar el contenido de la página dinámica real en cada página a través de JS para conservar la URL y, al mismo tiempo, permitir un almacenamiento en caché efectivo.
Andrew L
Sí, esa es prácticamente la forma en que GWT maneja esto por mí: Mi index.html (cambia ocasionalmente) incluye mymodule.nocache.js (cambia ocasionalmente), que incluye automáticamente los archivos correctos que se pueden almacenar en caché para siempre (grandes partes de js, GWT administrado paquetes de imágenes, ...) Lo único que me queda es configurar los encabezados http correctos para cada tipo. Quiero reducir estos encabezados al mínimo, ya que representan un gran porcentaje del volumen de transferencia. Entonces, ¿necesito, por ejemplo, tanto Last-Modified como ETag, etc.?
Chris Lercher
"Caduca" en realidad debe ser una fecha, no el número 0. Debe tener el mismo valor que el encabezado "Fecha". Ver mnot.net/cache_docs
Luke Hutchison