Intestazioni di caching HTTP: private vs no-cache

Question

Intestazioni di caching HTTP: private vs no-cache

#1 da (1 voti)

10

Stiamo attualmente esaminando il nostro set di intestazioni di sicurezza "senza cache":

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

Oltre all'impostazione "standard" riportata sopra, ho trovato questo articolo , che consiglia di combinare "no-cache" e "no-store" con "private". Per quanto ho capito la specifica dovrebbe essere sufficiente impostare "no-cache" e "no-store" se vuoi proibire il caching.

Quindi la mia domanda: Ci sono motivi per aggiungere l'intestazione "privata" al nostro set? E se è così, ci sarà un conflitto tra le intestazioni?

P.S .: Ho anche controllato le seguenti due discussioni, che non hanno fornito una risposta definitiva.

http caching http-proxy

posta Th0mas 04.08.2015 - 13:56

fonte

1 risposta

Leggi altre domande sui tag http caching http-proxy

Come isolare il dirottamento del browser pop-up persistente [chiuso] Iframe che eredita la politica di sicurezza dei contenuti dei genitori

score 1 · Answer 1

Capisco la contraddizione (se così possiamo chiamarla così) che hai evidenziato. Quindi leggo entrambi (alcune parti delle specifiche relative all'opzione private ) e l'articolo.

Ho piuttosto cercato l' articolo originale in cui è stato menzionato per la prima volta il bug. In quell'articolo, è dichiarato:

It was reported that multiple meta.wikimedia.org users received the same session ID. These users could act as the user who happened to be logged in according to the session value.

Quindi puoi concludere che non c'è niente di sbagliato nella specifica, e devi aggiungere l'opzione private in Cache-control solo quando c'è una sessione .