Encabezados de almacenamiento en caché HTTP: privado vs no-cache

Question

Encabezados de almacenamiento en caché HTTP: privado vs no-cache

10

Actualmente estamos revisando nuestro conjunto de encabezados de seguridad "sin caché":

Cache-Control "no-cache, no-store, must-revalidate
Pragma "no-cache"
Expires 0

Además del "estándar" establecido anteriormente, encontré este artículo , que recomienda combinar "no-cache" y "no-store" con "private". Según entiendo la especificación debería ser suficiente para establecer "no-cache" y "no-store" si quieres prohibir el almacenamiento en caché en absoluto.

Entonces, mi pregunta: ¿Hay alguna razón para agregar el encabezado "privado" a nuestro conjunto? Y si es así, ¿habrá un conflicto entre los encabezados?

P.S .: También revisé las siguientes dos discusiones, que no proporcionaron una respuesta definitiva.

http http-proxy caching

pregunta Th0mas 04.08.2015 - 13:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas http http-proxy caching

¿Cómo se ve afectada la seguridad de SSH en presencia de un MITM de monitoreo pasivo? En caso de que se reconsidere el riesgo de productos antivirus a la luz del informe de error crítico de TrendMicro [cerrado]

score 1 · Answer 1

Entiendo la contradicción (si podemos llamarlo así) resaltada. Así que leí tanto (algunas partes de la especificación relacionada con la opción privada ) como el artículo.

Prefiero buscar en el artículo original donde se mencionó el error por primera vez. En ese artículo, se afirma:

Se informó que varios usuarios de meta.wikimedia.org recibieron la Id. de sesión. Estos usuarios podrían actuar como el usuario que resultó ser ha iniciado sesión de acuerdo con el valor de la sesión.

Por lo tanto, puede concluir que no hay nada malo con la especificación y que necesita agregar la opción private en Cache-control solo cuando hay una sesión .