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!