Qual è la differenza tra Cache-Control: max-age = 0 e no-cache?

L'intestazione Cache-Control: max-age=0implica che il contenuto è considerato obsoleto (e deve essere recuperato immediatamente), il che è in effetti la stessa cosa di Cache-Control: no-cache.

Ho avuto la stessa domanda e ho trovato alcune informazioni nelle mie ricerche (la tua domanda è nata come uno dei risultati). Ecco cosa ho deciso ...

Ci sono due lati Cache-Controlnell'intestazione. Un lato è dove può essere inviato dal server web (aka "server di origine"). L'altro lato è dove può essere inviato dal browser (alias "user agent").

Quando inviato dal server di origine

Credo max-age=0semplicemente dica alla cache (e agli user agent) che la risposta è stantia fin dall'inizio e quindi DOVREBBERO riconvalidare la risposta (ad es. Con l' If-Not-Modifiedintestazione) prima di utilizzare una copia cache, mentre, no-cachedice loro che DEVONO riconvalidare prima di utilizzare una cache copia. Dal 14.9.1 Cosa è memorizzabile nella cache :

no-cache

... una cache NON DEVE utilizzare la risposta per soddisfare una richiesta successiva senza una riconvalida corretta con il server di origine. Ciò consente a un server di origine di impedire la memorizzazione nella cache anche da cache configurate per restituire risposte non aggiornate alle richieste del client.

In altre parole, le cache a volte possono scegliere di utilizzare una risposta non aggiornata (anche se credo che debbano quindi aggiungere Warningun'intestazione), ma no-cachedice che non è consentito utilizzare una risposta non valida in ogni caso. Forse dovresti DOVREBBE comportarsi in modo non valido quando le statistiche di baseball sono generate in una pagina, ma vorresti il comportamento DEVE invalidare quando hai generato la risposta a un acquisto di e-commerce.

Sebbene tu sia corretto nel tuo commento quando dici che no-cachenon dovrebbe impedire l'archiviazione, potrebbe effettivamente esserci un'altra differenza durante l'utilizzo no-cache. Mi sono imbattuto in una pagina, Direttive sul controllo della cache demistificata , che dice (non posso garantire la sua correttezza):

In pratica, IE e Firefox hanno iniziato a trattare la direttiva no-cache come se dicesse al browser di non memorizzare nemmeno nella cache la pagina. Abbiamo iniziato a osservare questo comportamento circa un anno fa. Sospettiamo che questo cambiamento sia stato provocato dall'uso diffuso (e scorretto) di questa direttiva per impedire la memorizzazione nella cache.

...

Si noti che negli ultimi tempi anche "cache-control: no-cache" ha iniziato a comportarsi come la direttiva "no-store".

A parte questo, mi sembra che Cache-Control: max-age=0, must-revalidatesostanzialmente dovrebbe significare la stessa cosa di Cache-Control: no-cache. Quindi forse questo è un modo per ottenere il comportamento DEVE invalidare no-cache, evitando l'apparente migrazione di no-cachefare la stessa cosa di no-store(cioè nessuna memorizzazione nella cache di sorta)?

Quando inviato dall'agente utente

Credo che la risposta di Shahkalpesh si applichi al lato agente utente. Puoi anche guardare 13.2.6 Disambiguare risposte multiple .

Se un agente utente invia una richiesta con Cache-Control: max-age=0(ovvero "riconvalida end-to-end"), ogni cache lungo il percorso ripristinerà la sua voce di cache (ad es. Con l' If-Not-Modifiedintestazione) fino al server di origine. Se la risposta è quindi 304 (non modificata), è possibile utilizzare l'entità memorizzata nella cache.

D'altra parte, l'invio di una richiesta con Cache-Control: no-cache(ovvero "ricarica end-to-end") non viene riconvalidato e il server NON DEVE utilizzare una copia memorizzata nella cache per rispondere.

max-age = 0

Ciò equivale a fare clic su Aggiorna , il che significa che mi dia l'ultima copia a meno che non abbia già l'ultima copia.

no-cache

Ciò tiene premuto Shift mentre si fa clic su Aggiorna, il che significa che basta ripetere tutto, qualunque cosa accada.

Vecchia domanda ora, ma se qualcun altro si imbatte in una ricerca come me, sembra che IE9 lo utilizzerà per configurare il comportamento delle risorse quando si utilizzano i pulsanti Indietro e Avanti. Quando si utilizza max-age = 0 , il browser utilizzerà l'ultima versione quando si visualizza una risorsa con una pressione avanti / indietro. Se non viene utilizzata la cache , la risorsa verrà recuperata.

Ulteriori dettagli sulla memorizzazione nella cache IE9 sono disponibili su questo post sul blog di cache msdn .

Nei miei recenti test con IE8 e Firefox 3.5, sembra che entrambi siano conformi a RFC. Tuttavia, differiscono nella loro "cordialità" rispetto al server di origine. IE8 tratta le no-cacherisposte con la stessa semantica di max-age=0,must-revalidate. Firefox 3.5, tuttavia, sembra considerare no-cacheequivalente a no-store, il che fa schifo per prestazioni e utilizzo della larghezza di banda.

Squid Cache, per impostazione predefinita, sembra non memorizzare mai nulla con no-cacheun'intestazione, proprio come Firefox.

Il mio consiglio sarebbe di impostare public,max-age=0le risorse non sensibili che si desidera aver verificato la freschezza per ogni richiesta, ma consentire comunque i vantaggi di prestazioni e larghezza di banda della memorizzazione nella cache. Per gli articoli per utente con la stessa considerazione, utilizzare private,max-age=0.

Eviterei completamente l'uso no-cache, poiché sembra che sia stato bastardizzato da alcuni browser e cache popolari all'equivalente funzionale di no-store.

Inoltre, non emulare Akamai e Limelight. Mentre essenzialmente gestiscono enormi array di memorizzazione nella cache come attività principale e dovrebbero essere esperti, in realtà hanno un interesse acquisito nel causare il download di più dati dalle loro reti. Google potrebbe non essere una buona scelta neanche per l'emulazione. Sembrano usare max-age=0o no-cachecasualmente a seconda della risorsa.

max-age
    Quando una cache intermedia viene forzata, mediante una direttiva max-age = 0, per riconvalidare 
la propria voce di cache e il client ha fornito il proprio validatore nella richiesta, il 
il validatore fornito potrebbe differire dal validatore attualmente memorizzato con la voce cache. 
In questo caso, la cache PU use utilizzare uno dei validatori per effettuare la propria richiesta senza 
influenzando la trasparenza semantica. 

    Tuttavia, la scelta del validatore potrebbe influire sulle prestazioni. L'approccio migliore è per il
cache intermedia per utilizzare il proprio validatore quando si effettua la richiesta. Se il server risponde
con 304 (non modificato), la cache può restituire al client la sua copia ora convalidata 
con una risposta 200 (OK). Se il server risponde con una nuova entità e validatore di cache,
tuttavia, la cache intermedia può confrontare il validatore restituito con quello fornito in 
la richiesta del cliente, utilizzando la forte funzione di confronto. Se il validatore del client è
uguale a quello del server di origine, la cache intermedia restituisce semplicemente 304 (No 
Modificato). Altrimenti, restituisce la nuova entità con una risposta 200 (OK).

    Se una richiesta include la direttiva no-cache, NON DOVREBBE includere min-fresh, 
max-stantio o max-age. 

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

Non accettarlo come risposta - dovrò leggerlo per capire il suo vero utilizzo :)

Non sono un esperto di cache, ma Mark Nottingham lo è. Ecco i suoi documenti di cache . Ha anche ottimi collegamenti nella sezione Riferimenti.

Sulla base della mia lettura di questi documenti, sembra che max-age=0la cache possa inviare una risposta memorizzata nella cache alle richieste che sono arrivate nello "stesso momento", dove "stesso tempo" significa che sono abbastanza vicini da sembrare simultanei alla cache, ma no-cachenon .

A proposito, vale la pena notare che alcuni dispositivi mobili, in particolare i prodotti Apple come iPhone / iPad, ignorano completamente le intestazioni come no-cache, no-store, Expires: 0 o qualsiasi altra cosa si possa provare a forzare a non riutilizzare scaduto pagine del modulo.

Questo non ci ha causato la fine del mal di testa mentre proviamo a far dire il problema dell'iPad di un utente, rimanendo addormentati su una pagina che hanno raggiunto attraverso un processo di forma, diciamo il passaggio 2 di 3, e quindi il dispositivo ignora completamente il negozio / le direttive della cache, e per quanto ne so, prende semplicemente ciò che è un'istantanea virtuale della pagina dal suo ultimo stato, cioè ignorando ciò che è stato detto esplicitamente e, non solo, prendendo una pagina che non dovrebbe essere memorizzata e memorizzarlo senza effettivamente controllarlo di nuovo, il che porta a tutti i tipi di strani problemi di sessione, tra le altre cose.

Sto solo aggiungendo questo nel caso in cui qualcuno si presenti e non riesca a capire perché stanno ricevendo errori di sessione con in particolare iPhone e iPad, che sembrano di gran lunga i peggiori trasgressori in quest'area.

Ho fatto test di debugger abbastanza estesi con questo problema, e questa è la mia conclusione, i dispositivi ignorano completamente queste direttive.

Anche nell'uso regolare, ho scoperto che alcuni cellulari non riescono nemmeno a controllare le nuove versioni tramite, Scade: 0 quindi controlla le ultime date modificate per determinare se dovrebbe averne una nuova.

Semplicemente non succede, quindi quello che sono stato costretto a fare è stato aggiungere stringhe di query ai file css / js di cui avevo bisogno per forzare gli aggiornamenti, il che induce gli stupidi dispositivi mobili a pensare che sia un file che non ha, come: mio .css? v = 1, quindi v = 2 per un aggiornamento css / js. Questo funziona in gran parte.

Inoltre, anche i browser degli utenti, se lasciati ai loro valori predefiniti, a partire dal 2016, come scopro continuamente (apportiamo MOLTE modifiche e aggiornamenti al nostro sito) non riescono a controllare le ultime date modificate su tali file, ma la query il metodo string risolve tale problema. Questo è qualcosa che ho notato con i clienti e le persone dell'ufficio che tendono a utilizzare le impostazioni predefinite dell'utente normale di base sui loro browser e non hanno consapevolezza dei problemi di memorizzazione nella cache con CSS / J ecc. il che significa che le impostazioni predefinite per i loro browser, principalmente MSIE / Firefox, non stanno facendo ciò che viene loro chiesto di fare, ignorano le modifiche e ignorano le ultime date modificate e non convalidano, anche con Expires: 0 impostato esplicitamente.

Questa è stata una buona discussione con molte buone informazioni tecniche, ma è anche importante notare quanto il supporto per questa roba sia particolarmente nei dispositivi mobili. Ogni pochi mesi devo aggiungere più livelli di protezione contro la loro incapacità di seguire i comandi di intestazione che ricevono, o di interpretare correttamente quei comandi.

Una cosa che (sorprendentemente) non è stata menzionata è che una richiesta può indicare esplicitamente che accetterà dati non aggiornati, usando la max-staledirettiva. In tal caso, se il server rispondesse max-age=0, la cache considererebbe semplicemente la risposta obsoleta e sarebbe libera di usarla per soddisfare la richiesta del client [che richiedeva dati potenzialmente non aggiornati]. Al contrario, se il server invia no-cacheche realmente supera qualsiasi richiesta da parte del client (con max-stale) per dati non aggiornati, poiché la cache DEVE riconvalidare.

La differenza è che no-cache (no-store su Firefox) impedisce qualsiasi tipo di cache. Ciò può essere utile per impedire la scrittura su disco di pagine con contenuto protetto e per le pagine che devono sempre essere aggiornate anche se vengono nuovamente visitate con il pulsante Indietro.

max-age = 0 indica che una voce della cache è obsoleta e richiede una nuova convalida, ma non impedisce la memorizzazione nella cache. Spesso i browser convalidano le risorse solo una volta per sessione del browser, quindi il contenuto potrebbe non essere aggiornato fino a quando il sito non viene visitato in una nuova sessione.

Di solito, i browser non eliminano le voci della cache scadute, a meno che non stiano recuperando lo spazio per i contenuti più recenti quando la cache del browser è piena. Utilizzando no-store, no-cache consente di eliminare esplicitamente una voce della cache.