Diferencia entre no-cache y must-revalidate

Desde el RFC 2616

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

sin caché

Si la directiva sin caché no especifica un nombre de campo, entonces 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 de los clientes.

Por lo tanto, indica a los agentes que revaliden todas las respuestas.

Comparado esto con

debe revalidar

Cuando la directiva must-revalidate está presente en una respuesta recibida por un caché, ese caché NO DEBE usar la entrada después de que se vuelva obsoleta para responder a una solicitud posterior sin primero revalidarla con el servidor de origen

Por lo tanto, indica a los agentes que revaliden las respuestas obsoletas .

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

¿De qué sirve no-cachesi hay must-revalidatey max-age?

Ver este comentario:

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

sin caché

Aunque esta directiva parece indicarle al navegador que no guarde en caché la página, hay una sutil diferencia. La directiva "sin caché", según 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 que la aplicación conserve el ancho de banda. Si la página que el navegador ha almacenado en caché no ha cambiado, el servidor solo se lo indica al navegador y la página se muestra desde la memoria 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 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.

¿Alguien tiene algo más oficial sobre esto?

Actualizar

La directiva debe revalidar debe ser utilizada por los servidores si y solo si la falta de validación de una solicitud en la representación puede resultar en una operación incorrecta, como una transacción financiera silenciosamente no ejecutada.

Eso es algo que nunca me había tomado en serio hasta ahora. El RFC dice que no se debe usar la revalidación a la ligera. La cuestión es que, con los servicios web, debe tener una visión negativa y asumir lo peor para sus aplicaciones de 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 nuevamente. 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 revalidar adecuadamente a menos que la solicitud también incluya otros encabezados que luego causen 'revalidar siempre' de todos modos.

Solo quiero aclarar ese último punto. Simplemente configurando must-revalidatepero 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 se incluyen ETag o datos de encabezado modificado en las respuestas, los agentes siempre revalidan de todos modos, independientemente de la presencia del must-revalidateencabezado.

Por lo tanto, el punto must-revalidatees forzar una 'omisión de caché' cuando se vuelve obsoleta, lo que solo puede suceder cuando ha establecido una vida / edad, por lo tanto, si must-revalidatese configura en una respuesta sin edad u otros encabezados, se vuelve efectivamente equivalente a no-cachedesde la respuesta se considerará inmediatamente obsoleta.

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

Creo que eso must-revalidatesignifica:

Una vez que la memoria caché caduca, rechace devolver respuestas obsoletas al usuario, incluso si dicen que las respuestas obsoletas son aceptables.

Mientras que no-cacheimplica:

must-revalidate más el hecho de que la respuesta se vuelve obsoleta de inmediato.

Si una respuesta se puede almacenar en caché durante 10 segundos, se must-revalidateactiva después de 10 segundos, mientras que no-cacheimplica must-revalidatedespués de 0 segundos.

Al menos, esa es mi interpretación.

max-age=0, must-revalidatey no-cacheno son exactamente idénticos Con must-revalidate, si el servidor no responde a una solicitud de revalidación, se supone que el navegador / proxy devolverá un error 504. Con no-cache, solo mostraría el contenido almacenado en caché, que probablemente sería preferido por el usuario (mejor tener algo obsoleto que nada). Es por eso que must-revalidateestá destinado solo a transacciones críticas.

Con la interpretación de Jeffrey Fox sobre no-cache, he probado bajo Chrome 52.0.2743.116 m, el resultado muestra que no-cachetiene el mismo comportamiento que must-revalidate, todos ellos NO usarán caché local cuando el servidor no es accesible, y todos usarán caché mientras presionan la parte posterior del navegador / Botón de reenvío cuando el servidor no es accesible Como arriba, creo que max-age=0, must-revalidatees idéntico no-cache, al menos en la implementación.

Creo que hay una diferencia entre max-age=0, must-revalidatey no-cache:

En el must-revalidatecaso, el cliente puede enviar una If-Modified-Sincesolicitud y servir la respuesta de la memoria caché si 304 Not Modifiedse devuelve.

En el no-cachecaso, el cliente no debe almacenar en caché la respuesta, por lo que no debe usarla If-Modified-Since.