¿Cuál es la diferencia entre Cache-Control: max-age = 0 y no-cache?

El encabezado Cache-Control: max-age=0implica que el contenido se considera obsoleto (y debe volverse a buscar) inmediatamente, lo que en efecto es lo mismo que Cache-Control: no-cache.

Tenía la misma pregunta y encontré información en mis búsquedas (su pregunta apareció como uno de los resultados). Esto es lo que determiné ...

Hay dos lados en el Cache-Controlencabezado. Un lado es donde puede ser enviado por el servidor web (también conocido como "servidor de origen"). El otro lado es donde puede ser enviado por el navegador (también conocido como "agente de usuario").

Cuando lo envía el servidor de origen

Creo que max-age=0simplemente le dice a los cachés (y a los agentes de usuario) que la respuesta está obsoleta desde el principio y, por lo tanto, DEBERÍAN revalidar la respuesta (por ejemplo, con el If-Not-Modifiedencabezado) antes de usar una copia en caché, mientras no-cacheque les dice que DEBEN revalidar antes de usar un caché Copiar. Desde 14.9.1 Qué es el Cacheable :

sin caché

... un caché NO DEBE usar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen. Esto permite que un servidor de origen evite el almacenamiento en caché incluso en cachés que se han configurado para devolver respuestas obsoletas a las solicitudes del cliente.

En otras palabras, los cachés a veces pueden optar por usar una respuesta obsoleta (aunque creo que tienen que agregar un Warningencabezado), pero no-cachedice que no se les permite usar una respuesta obsoleta sin importar qué. Tal vez desee el comportamiento DEBEN validar cuando las estadísticas de béisbol se generan en una página, pero querrá el comportamiento DEBEN validar cuando haya generado la respuesta a una compra de comercio electrónico.

Aunque está en lo correcto en su comentario cuando dice que no-cachese supone que no debe evitar el almacenamiento, en realidad podría ser otra diferencia al usarlo no-cache. Encontré una página, Directivas de control de caché desmitificadas , que dice (no puedo responder por su corrección):

En la práctica, IE y Firefox han comenzado a tratar la directiva sin caché como si le indicara al navegador que ni siquiera guarde en caché la página. Comenzamos a observar este comportamiento hace aproximadamente un año. Sospechamos que este cambio fue impulsado por el uso generalizado (e incorrecto) de esta directiva para evitar el almacenamiento en caché.

...

Observe que últimamente, "cache-control: no-cache" también ha comenzado a comportarse como la directiva "no-store".

Como comentario, me parece que Cache-Control: max-age=0, must-revalidatebásicamente debería significar lo mismo que Cache-Control: no-cache. Entonces, ¿tal vez sea una forma de obtener el comportamiento que DEBE volver a validar no-cache, evitando al mismo tiempo la aparente migración de no-cachehacer lo mismo que no-store(es decir, sin almacenamiento en caché)?

Cuando lo envía el agente de usuario

Creo que la respuesta de shahkalpesh se aplica al lado del agente de usuario. También puede ver 13.2.6 Desambiguación de respuestas múltiples .

Si un agente de usuario envía una solicitud con Cache-Control: max-age=0(también conocido como "revalidación de extremo a extremo"), cada caché en el camino revalidará su entrada de caché (por ejemplo, con el If-Not-Modifiedencabezado) hasta el servidor de origen. Si la respuesta es 304 (no modificada), se puede usar la entidad en caché.

Por otro lado, enviar una solicitud con Cache-Control: no-cache(también conocido como "recarga de extremo a extremo") no se revalida y el servidor NO DEBE usar una copia en caché al responder.

max-age = 0

Esto es equivalente a hacer clic en Actualizar , lo que significa, darme la última copia a menos que ya tenga la última copia.

sin caché

Esto mantiene presionada la tecla Mayús mientras hace clic en Actualizar, lo que significa que simplemente rehaga todo sin importar qué.

Vieja pregunta ahora, pero si alguien más se encuentra con esto a través de una búsqueda como lo hice yo, parece que IE9 hará uso de esto para configurar el comportamiento de los recursos al usar los botones de retroceso y avance. Cuando se usa max-age = 0 , el navegador usará la última versión cuando vea un recurso en una pulsación hacia atrás / adelante. Si no se usa caché , el recurso se volverá a buscar.

Se pueden ver más detalles sobre el almacenamiento en caché de IE9 en esta publicación de blog de almacenamiento en caché de msdn .

En mis pruebas recientes con IE8 y Firefox 3.5, parece que ambos cumplen con RFC. Sin embargo, difieren en su "amabilidad" con el servidor de origen. IE8 trata las no-cacherespuestas con la misma semántica que max-age=0,must-revalidate. Firefox 3.5, sin embargo, parece tratarse no-cachecomo equivalente ano-store , lo que apesta al rendimiento y al uso del ancho de banda.

Squid Cache, por defecto, parece que nunca almacena nada con un no-cacheencabezado, al igual que Firefox.

Mi consejo sería establecer public,max-age=0recursos no confidenciales que desee que verifiquen la actualización en cada solicitud, pero que aún permitan los beneficios de rendimiento y ancho de banda del almacenamiento en caché. Para artículos por usuario con la misma consideración, use private,max-age=0.

Evitaría el uso por no-cachecompleto, ya que parece que algunos navegadores y cachés populares lo han bastardado al equivalente funcional de no-store.

Además, no emule Akamai y Limelight. Si bien esencialmente ejecutan matrices de almacenamiento en caché masivas como su negocio principal, y deberían ser expertos, en realidad tienen un gran interés en hacer que se descarguen más datos de sus redes. Google podría no ser una buena opción para la emulación, tampoco. Parecen usar max-age=0o no-cacheal azar dependiendo del recurso.

edad máxima
    Cuando una caché intermedia es forzada, por medio de una directiva max-age = 0, a revalidar 
su propia entrada de caché, y el cliente ha proporcionado su propio validador en la solicitud, el 
el validador suministrado puede diferir del validador actualmente almacenado con la entrada de caché. 
En este caso, el caché PUEDE usar cualquiera de los validadores al hacer su propia solicitud sin 
que afecta la transparencia semántica. 

    Sin embargo, la elección del validador puede afectar el rendimiento. El mejor enfoque es para el
caché intermedio para usar su propio validador al hacer su solicitud. Si el servidor responde
con 304 (no modificado), entonces el caché puede devolver su copia ahora validada al cliente 
con una respuesta 200 (OK). Si el servidor responde con una nueva entidad y un validador de caché,
sin embargo, el caché intermedio puede comparar el validador devuelto con el proporcionado en 
La solicitud del cliente, utilizando la función de comparación fuerte. Si el validador del cliente es
igual al servidor de origen, entonces el caché intermedio simplemente devuelve 304 (No 
Modificado). De lo contrario, devuelve la nueva entidad con una respuesta 200 (OK).

    Si una solicitud incluye la directiva sin caché, NO DEBE incluir min-fresh, 
max-stale, o max-age. 

cortesía: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

No acepte esto como respuesta. Tendré que leerlo para comprender su verdadero uso :)

Apenas soy un experto en caché, pero Mark Nottingham lo es. Aquí están sus documentos de almacenamiento en caché . También tiene excelentes enlaces en la sección de Referencias.

Según mi lectura de esos documentos, parece que max-age=0podría permitir que el caché envíe una respuesta en caché a las solicitudes que llegaron en el "mismo tiempo", donde "mismo tiempo" significa que lo suficientemente cerca como para parecer simultáneos al caché, pero no-cacheno .

Por cierto, vale la pena señalar que algunos dispositivos móviles, en particular los productos de Apple, como iPhone / iPad, ignoran por completo los encabezados como no-cache, no-store, Expires: 0, o cualquier otra cosa que intentes forzarlos para que no vuelvan a usarse. páginas de formulario

Esto nos ha causado un sinfín de dolores de cabeza al tratar de resolver el problema del iPad de un usuario, quedando dormido en una página a la que han llegado a través de un proceso de formulario, digamos el paso 2 de 3, y luego el dispositivo ignora por completo la tienda / directivas de caché, y por lo que puedo decir, simplemente toma lo que es una instantánea virtual de la página desde su último estado, es decir, ignora lo que se dijo explícitamente y, no solo eso, toma una página que no debe almacenarse y almacenarlo sin volver a comprobarlo, lo que genera todo tipo de problemas extraños en la sesión, entre otras cosas.

Solo estoy agregando esto en caso de que alguien aparezca y no pueda entender por qué están recibiendo errores de sesión con particularmente iphones e ipads, que parecen ser, con mucho, los peores delincuentes en esta área.

He realizado pruebas de depuración bastante extensas con este problema, y ​​esta es mi conclusión, los dispositivos ignoran estas directivas por completo.

Incluso en el uso regular, descubrí que algunos móviles tampoco comprueban por completo nuevas versiones a través de, por ejemplo, Expira: 0 y luego verificando las últimas fechas modificadas para determinar si debería obtener una nueva.

Simplemente no sucede, así que lo que me obligaron a hacer fue agregar cadenas de consulta a los archivos css / js que necesitaba para forzar las actualizaciones, lo que engaña a los estúpidos dispositivos móviles a pensar que es un archivo que no tiene, como: mi .css? v = 1, luego v = 2 para una actualización css / js. Esto funciona en gran medida.

Los navegadores de los usuarios también, por cierto, si se dejan a sus valores predeterminados, a partir de 2016, como descubro continuamente (hacemos MUCHOS cambios y actualizaciones en nuestro sitio) tampoco pueden verificar las últimas fechas modificadas en dichos archivos, pero la consulta El método de cadena corrige ese problema. Esto es algo que he notado con clientes y personal de oficina que tienden a usar los valores predeterminados básicos de los usuarios normales en sus navegadores, y no tienen conocimiento de los problemas de almacenamiento en caché con css / js, etc. lo que significa que los valores predeterminados para sus navegadores, principalmente MSIE / Firefox, no están haciendo lo que se les dice que hagan, ignoran los cambios e ignoran las últimas fechas de modificación y no validan, incluso con Expires: 0 establecido explícitamente.

Este fue un buen hilo con mucha buena información técnica, pero también es importante tener en cuenta cuán malo es el soporte para estas cosas en dispositivos móviles en particular. Cada pocos meses tengo que agregar más capas de protección contra su falla al seguir los comandos de encabezado que reciben, o para interpretar adecuadamente esos comandos.

Una cosa que (sorprendentemente) no se ha mencionado es que una solicitud puede indicar explícitamente que aceptará datos obsoletos, utilizando la max-staledirectiva. En ese caso, si el servidor respondiera max-age=0, la memoria caché simplemente consideraría la respuesta obsoleta y sería libre de usarla para satisfacer la solicitud del cliente [que solicitó datos potencialmente obsoletos]. Por el contrario, si el servidor envía no-cacheeso realmente supera cualquier solicitud del cliente (con max-stale) de datos obsoletos, ya que el caché DEBE revalidar.

La diferencia es que no-cache (no-store en Firefox) evita cualquier tipo de almacenamiento en caché. Eso puede ser útil para evitar que las páginas con contenido seguro se escriban en el disco y para las páginas que siempre deben actualizarse, incluso si se vuelven a visitar con el botón Atrás.

max-age = 0 indica que una entrada de caché está obsoleta y requiere una nueva validación, pero no evita el almacenamiento en caché. A menudo, los navegadores solo validan los recursos una vez por sesión de navegador, por lo que es posible que el contenido no se actualice hasta que se visite el sitio en una nueva sesión.

Por lo general, los navegadores no eliminarán las entradas de memoria caché caducadas, a menos que estén reclamando el espacio para contenido más nuevo cuando la memoria caché del navegador esté llena. Usando no-store, no-cache permite que una entrada de caché se elimine explícitamente.