¿Diferencia entre no caché y debe revalidar para Cache-Control?
Del 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 revalidarla primero con el servidor de origen.
Por lo tanto, ordena a los agentes que revaliden las respuestas obsoletas .
En particular no-cache, ¿es así como los agentes de usuario tratan empíricamente esta directiva?
¿Cuál es el punto de no-cachesi hay must-revalidatey max-age?
Vea este comentario:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
sin caché
Aunque esta directiva parece indicarle al navegador que no almacene en caché la página, hay una diferencia sutil. La directiva "no-cache", 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 ingeniosa 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 se lo indica al navegador y la página se muestra desde el caché. Por lo tanto, el navegador (al menos en teoría) almacena la página en su caché, pero la muestra solo después de revalidarla 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 almacene 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 tiene algo más oficial sobre esto?
Actualizar
Los servidores deben utilizar la directiva must-revalidate si y solo si no validar una solicitud en la representación podría resultar en una operación incorrecta, como una transacción financiera no ejecutada silenciosamente.
Eso es algo que nunca me había tomado en serio hasta ahora. El RFC dice que no se debe utilizar la revalidación obligatoria a la ligera. La cuestión es que, con los servicios web, debes adoptar 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 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 tengan un nombre deficiente, ya que no se pueden revalidar adecuadamente a menos que la solicitud también incluya otros encabezados que luego causen "revalidar siempre" de todos modos.
Sólo quiero dejar más claro ese último punto. Simplemente configurando must-revalidatepero sin incluir una 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 modificados en las respuestas, los agentes siempre revalidan de todos modos, independientemente de la presencia del must-revalidateencabezado.
Entonces, el objetivo must-revalidatees forzar una 'omisión de caché' cuando se vuelve obsoleto, lo que solo puede suceder cuando se ha establecido una vida/edad, por lo tanto, si se must-revalidateestablece en una respuesta sin edad u otros encabezados, efectivamente se vuelve 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 caduque el caché, rechace devolver respuestas obsoletas al usuario incluso si dice que las respuestas obsoletas son aceptables.
Mientras que no-cacheimplica:
must-revalidateademás del 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, simplemente mostraría el contenido almacenado en caché, que probablemente sería el preferido por el usuario (es mejor tener algo obsoleto que nada en absoluto). Es por eso must-revalidateque está destinado únicamente a transacciones críticas.
Con la interpretación de Jeffrey Fox sobre no-cacheChrome 52.0.2743.116 m, el resultado muestra que no-cachetiene el mismo comportamiento que must-revalidate, todos NO usarán el caché local cuando el servidor sea inaccesible y todos usarán el caché mientras tocan Atrás del navegador. Botón /Adelante cuando no se puede acceder al servidor. Como lo anterior, creo max-age=0, must-revalidateque es idéntico no-cache, al menos en la implementación.
Por si sirve de algo, la página de MDN sobre validación HTTP aborda directamente esto (el énfasis es mío):
Se suele afirmar que la combinación de
max-age=0ymust-revalidatetiene el mismo significado queno-cache.Cache-Control: max-age=0, must-revalidate
max-age=0significa que la respuesta queda inmediatamente obsoleta ymust-revalidatesignifica que no se debe reutilizar sin revalidación una vez que esté obsoleta; por lo que, en combinación, la semántica parece ser la misma queno-cache.Sin embargo, ese uso de
max-age=0es un remanente del hecho de que muchas implementaciones anteriores a HTTP/1.1 no podían manejar lano-cachedirectiva y, por lo tanto, para abordar esa limitación,max-age=0se utilizó como solución alternativa.Pero ahora que los servidores compatibles con HTTP/1.1 están ampliamente implementados, no hay razón para usar esa combinación
max-age=0-y-must-revalidate; en su lugar, simplemente debería usarno-cache.
Como referencia (para nuestro control de caché personal, je), esa página de MDN se actualizó por última vez el 1 de junio de 2022; y saqué esa cita el 10 de junio de 2022 ( archivo del 8 de junio ).
