http - must - header control cache

Diferencia entre no-cache y must-revalidate

Question

De la RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

no-caché

Si la directiva no-cache no especifica un nombre de campo, entonces un caché NO DEBE utilizar 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 mediante cachés que se han configurado para devolver respuestas obsoletas a las solicitudes de los clientes.

Por lo tanto, dirige a los agentes a revalidar todas las respuestas.

Comparado con esto

debe-revalidar

Cuando la directiva debe revalidarse está presente en una respuesta recibida por un caché, ese caché NO DEBE utilizar la entrada después de que quede obsoleta para responder a una solicitud posterior sin antes revalidarla con el servidor de origen.

Por lo tanto, dirige a los agentes a revalidar respuestas obsoletas .

Particularmente con respecto a no-cache , ¿es así como los agentes de usuario realmente tratan empíricamente esta directiva?

¿Cuál es el punto de no-cache si hay must-revalidate y max-age ?

Ver este comentario:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

no-caché

Aunque esta directiva parece indicar al navegador que no almacene en caché la página, existe una sutil diferencia. La directiva "no-cache", de acuerdo con el RFC, le dice al navegador que debe revalidar con el servidor antes de servir la página desde el caché. La revalidación es una técnica ordenada que permite a la aplicación conservar el ancho de banda. Si la página que el navegador ha almacenado en caché no ha cambiado, el servidor simplemente lo señala al navegador y la página se muestra desde el caché. Por lo tanto, el navegador (en teoría, al menos) almacena la página en su caché, pero la muestra solo después de revalidar con el servidor. En la práctica, IE y Firefox han comenzado a tratar la directiva de no-caché como si ordenara al navegador ni siquiera almacenar en caché la página. Comenzamos a observar este comportamiento hace aproximadamente un año. Sospechamos que este cambio fue provocado por el uso generalizado (e incorrecto) de esta directiva para evitar el almacenamiento en caché.

¿Alguien ha conseguido algo más oficial sobre esto?

Actualizar

Los servidores deben usar la directiva de debe revalidar si y solo si la falla al validar una solicitud en la representación podría resultar en un funcionamiento incorrecto, como una transacción financiera silenciosamente no ejecutada.

Eso es algo que nunca me había tomado en serio hasta ahora. El RFC está diciendo que no se debe usar debe revalidar a la ligera. Lo que pasa es que, con los servicios web, debes tener una visión negativa y asumir lo peor para tus aplicaciones cliente desconocidas. Cualquier recurso obsoleto tiene el potencial de causar un problema.

Y algo más que acabo de considerar, sin Last-Modified o ETags, el navegador solo puede recuperar todo el recurso. Sin embargo, con ETags, he observado que Chrome al menos parece revalidar en cada solicitud. Lo que hace que ambas directivas sean discutibles o al menos mal nombradas, ya que no pueden revalidarse adecuadamente a menos que la solicitud también incluya otros encabezados que luego causan ''siempre revalidar'' de todos modos.

Solo quiero aclarar ese último punto. Con solo establecer must-revalidate pero sin incluir un ETag o Last-Modified, el agente solo puede obtener el contenido nuevamente ya que no tiene nada que enviar al servidor para comparar.

Sin embargo, mis pruebas empíricas han demostrado que cuando ETag o los datos modificados del encabezado se incluyen en las respuestas, los agentes siempre revalidan de todos modos, independientemente de la presencia del encabezado must-revalidate .

Por lo tanto, el punto de must-revalidate es forzar un ''caché de derivación'' cuando se queda obsoleto, lo que solo puede ocurrir cuando se establece una duración / edad, por lo que si se must-revalidate se establece en una respuesta sin antigüedad u otros encabezados. efectivamente se vuelve equivalente a no-cache ya que la respuesta se considerará inmediatamente obsoleta.

- ¡Así que finalmente voy a marcar la respuesta de Gili!

Answer 1

Con la interpretación de Jeffrey Fox sobre no-cache , he probado bajo Chrome 52.0.2743.116 m, el resultado muestra que no-cache tiene el mismo comportamiento que must-revalidate , todos NO usarán caché local cuando el servidor no está accesible, y todos usarán la memoria caché mientras el botón Atrás / Adelante del buscador toque cuando el servidor no está disponible. Como arriba, creo max-age=0, must-revalidate es idéntico a no-cache , al menos en la implementación.

Answer 2

Creo que must-revalidate significa que "una vez que el caché expira, se niegan a devolver las respuestas obsoletas al usuario, incluso si dicen que las respuestas obsoletas son aceptables". Considerando que no-cache implica must-revalidate más el hecho de que la respuesta se vuelve obsoleta de inmediato.

Si una respuesta es almacenable en caché durante 10 segundos, entonces must-revalidate patadas después de 10 segundos, mientras que no-cache implica must-revalidate después de 0 segundos.

Al menos, esa es mi interpretación.

Answer 3

max-age=0, must-revalidate y no-cache no son exactamente idénticos. Con must-revalidate , si el servidor no responde a una solicitud de revalidación, el navegador / proxy debe devolver un error 504. Con no-cache , solo mostraría el contenido en caché, que probablemente sería preferido por el usuario (mejor tener algo rancio que nada en absoluto). Esta es la razón por la cual must-revalidate solo para transacciones críticas.