Dall'RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
no-cache
Se la direttiva no-cache non specifica un nome campo, una cache NON DEVE utilizzare la risposta per soddisfare una richiesta successiva senza riconvalida riuscita 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.
Quindi indirizza gli agenti a riconvalidare tutte le risposte.
Rispetto a
must-revalidate
Quando la direttiva must-revalidate è presente in una risposta ricevuta da una cache, quella cache NON DEVE utilizzare la voce dopo che è diventata obsoleta per rispondere a una richiesta successiva senza prima riconvalidarla con il server di origine
Quindi indirizza gli agenti a riconvalidare le risposte obsolete .
Soprattutto per quanto riguarda no-cache, è così che gli user agent trattano empiricamente questa direttiva?
Che senso ha no-cachese c'è must-revalidatee max-age?
Vedi questo commento:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
no-cache
Anche se questa direttiva sembra indicare al browser di non memorizzare nella cache la pagina, c'è una sottile differenza. La direttiva "no-cache", secondo RFC, dice al browser che dovrebbe riconvalidarsi con il server prima di servire la pagina dalla cache. La riconvalida è una tecnica accurata che consente all'applicazione di conservare la larghezza di banda. Se la pagina memorizzata nella cache del browser non è cambiata, il server lo segnala al browser e la pagina viene visualizzata dalla cache. Quindi, il browser (almeno in teoria), memorizza la pagina nella sua cache, ma la visualizza solo dopo la riconvalida con il server. 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.
Qualcuno ha qualcosa di più ufficiale su questo?
Aggiornare
La direttiva must-revalidate dovrebbe essere utilizzata dai server se e solo se la mancata convalida di una richiesta sulla rappresentazione potrebbe comportare un funzionamento errato, come una transazione finanziaria silenziosamente non eseguita.
È qualcosa che non ho mai preso a cuore fino ad ora. La RFC sta dicendo di non usare il leggero revalidare. Il fatto è che, con i servizi Web, devi avere una visione negativa e assumere il peggio per le tue app client sconosciute. Qualsiasi risorsa stantia ha il potenziale per causare un problema.
E qualcos'altro che ho appena preso in considerazione, senza Last-Modified o ETags, il browser può recuperare nuovamente l'intera risorsa. Tuttavia, con ETags, ho osservato che Chrome sembra almeno riconvalidare su ogni richiesta. Il che rende entrambe queste direttive discutibili o per lo meno mal nominate poiché non possono essere correttamente riconvalidate a meno che la richiesta non includa anche altre intestazioni che causano comunque "sempre riconvalidare" comunque.
Voglio solo chiarire quest'ultimo punto. Impostando must-revalidatema non includendo un ETag o Last-Modified, l'agente può ottenere di nuovo il contenuto solo perché non ha nulla da inviare al server per il confronto.
Tuttavia, i miei test empirici hanno dimostrato che quando ETag o i dati modificati dell'intestazione sono inclusi nelle risposte, gli agenti si riconvalidano sempre, indipendentemente dalla presenza must-revalidatedell'intestazione.
Quindi il punto di must-revalidateè forzare una 'cache di bypass' quando diventa stantio, il che può accadere solo quando hai impostato una vita / età, quindi se must-revalidateimpostato su una risposta senza età o altre intestazioni, diventa effettivamente equivalente a no-cacheda la risposta sarà considerata immediatamente stantia.
- Quindi segnerò finalmente la risposta di Gili!