HTTP
Memorizzazione nella cache delle risposte HTTP

Android Angular 2 AngularJS C# Language HTML Java Language JavaScript Node.js PHP Python Language
Ricerca…


Osservazioni

Le risposte vengono memorizzate nella cache separatamente per ogni URL e ogni metodo HTTP.

Il caching HTTP è definito in RFC 7234 .

Glossario

  • fresco - stato di una risposta memorizzata nella cache, che non è ancora scaduta. In genere, una nuova risposta può soddisfare le richieste senza la necessità di contattare il server da cui ha origine la risposta.
  • stantio - stato di una risposta memorizzata nella cache, che ha superato la data di scadenza. In genere, le risposte obsolete non possono essere utilizzate per soddisfare una richiesta senza verificare con il server se è ancora valida.
  • soddisfare - risposta in cache soddisfa una richiesta quando tutte le condizioni della domanda corrisponde la risposta in cache, ad esempio, hanno lo stesso metodo HTTP e URL, la risposta è fresco o la richiesta permette risposte stantie, intestazioni di richiesta corrispondono intestazioni elencate nella risposta di Vary intestazione, ecc .
  • riconvalida - verifica se una risposta memorizzata nella cache è recente. Questo di solito è fatto con una richiesta condizionale contenente If-Modified-Since o If-None-Match e lo stato della risposta 304 .
  • cache privata - cache per un singolo utente, ad esempio in un browser web. Le cache private possono memorizzare risposte personalizzate.
  • cache pubblica - cache condivisa tra molti utenti, ad esempio in un server proxy. Tale cache può inviare la stessa risposta a più utenti.

Risposta della cache per tutti per 1 anno

Cache-Control: public, max-age=31536000

public significa che la risposta è la stessa per tutti gli utenti (non contiene alcuna informazione personalizzata). max-age è in secondi da ora. 31536000 = 60 * 60 * 24 * 365.

Questo è raccomandato per le risorse statiche che non si intende mai modificare.

Risposta personalizzata in cache per 1 minuto

Cache-Control: private, max-age=60

private specifica che la risposta può essere memorizzata nella cache solo per l'utente che ha richiesto la risorsa e non può essere riutilizzata quando altri utenti richiedono la stessa risorsa. Questo è appropriato per le risposte che dipendono dai cookie.

Interrompere l'uso delle risorse memorizzate nella cache senza prima verificare con il server

Cache-Control: no-cache

Il client si comporterà come se la risposta non fosse stata memorizzata nella cache. Questo è appropriato per risorse che possono cambiare in modo imprevedibile in qualsiasi momento e che gli utenti devono sempre vedere nell'ultima versione.

Le risposte con no-cache saranno più lente (latenza elevata) a causa della necessità di contattare il server ogni volta che vengono utilizzate.

Tuttavia, per risparmiare larghezza di banda, i client possono ancora memorizzare tali risposte. Le risposte con no-cache non verranno utilizzate per soddisfare le richieste senza contattare il server ogni volta per verificare se è possibile riutilizzare la risposta memorizzata nella cache.

Richiedi risposte da non memorizzare affatto

 Cache-control: no-store

Indica ai clienti di non memorizzare nella cache la risposta in alcun modo e di dimenticarla al più presto possibile.

Questa direttiva è stata originariamente progettata per dati sensibili (oggi dovrebbe essere usato HTTPS), ma può essere utilizzata per evitare l'inquinamento delle cache con risposte che non possono essere riutilizzate.

È appropriato solo in casi specifici in cui i dati di risposta sono sempre diversi, ad esempio un endpoint API che restituisce un numero casuale elevato. In caso contrario, è possibile utilizzare no-cache e revalidation per avere un comportamento di risposta "non memorizzabile", pur conservando una certa larghezza di banda.

Intestazioni obsolete, ridondanti e non standard

  • Expires : specifica la data in cui la risorsa diventa obsoleta. Si basa su server e client che hanno orologi precisi e che supportano correttamente i fusi orari. Cache-control: max-age ha la precedenza su Expires ed è generalmente più affidabile.

  • post-check direttive post-check e pre-check sono estensioni di Internet Explorer non standard che consentono l'utilizzo di risposte obsolete. L'alternativa standard è stale-while-revalidate .

  • Pragma: no-cache - obsoleto nel 1999 . Cache-control posto dovrebbe essere usato il Cache-control .

Modifica delle risorse memorizzate nella cache

Il metodo più semplice per ignorare la cache è modificare l'URL. Questo è usato come best practice quando l'URL contiene una versione o un checksum della risorsa, ad es 

http://example.com/image.png?version=1
http://example.com/image.png?version=2

Questi due URL verranno memorizzati nella cache separatamente, quindi anche se …?version=1 stato memorizzato nella cache per sempre , una nuova copia potrebbe essere immediatamente recuperata come …?version=2 .

Si prega di non utilizzare URL casuali per bypassare le cache. Usa Cache-control: no-cache o Cache-control: no-store . Se le risposte con URL casuali vengono inviate senza la direttiva no-store , verranno memorizzate inutilmente nella cache e verranno inviate fuori dalla cache più risposte utili, degradando le prestazioni dell'intera cache.



Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow