Il protocollo HTTP è il vettore privilegiato per i servizi Internet attivi nel mondo: ci riferiamo al World Wide Web, il cosiddetto WWW,  ma non solo. Lo scaricamento di dati e immagini riguarda buona parte delle risorse che tale protocollo impiega e il traffico generato può essere ridotto sfruttando il meccanismo di caching già appartenente al protocollo. La cache permette al client (browser o nostre applicazioni) di conservare parte dei dati ottenuti da remoto e riutilizzarli per rispondere a richieste future, senza necessità di scaricarli nuovamente dal server. La finalità di un tale meccanismo è evidente: risparmiamo banda, dati e tempo, guadagnando in efficienza.

I dati salvati nella cache locale delle applicazioni devono essere conservati insieme ad una serie di informazioni accessorie come l’URL dal quale sono stati ottenuti, data/ora di scaricamento ed opzionalmente altro. In sè stesso, si tratta di un meccanismo semplice da comprendere e implementare, semmai il punto critico è capire fin quando tali dati saranno disponibili e come richiederli al server affinchè vengano applicati i vantaggi del caching. Apprezzare il funzionamento della cache è fondamentale in quanto permette di sfruttarne i benefici e se ne può trarre vantaggio sia lavorando lato server sia lato client come, ad esempio, nelle applicazioni mobile. In quest’ultimo caso si ricorderà che diverse librerie gestiscono già il meccanismo di cache (si pensi a Volley per Android) ma per farne buon uso è fondamentale averlo compreso a fondo. In questo articolo, ne approfondiremo il funzionamento vedendo alcuni esempi in cui i dati scaricati si pongono in modo diverso rispetto al meccanismo di cache e analizzeremo bene lo scambio di informazioni mediante l’app Postman di cui abbiamo parlato già su questo sito.

Header HTTP e cache

Ricordiamo che una richiesta o risposta HTTP è suddivisa in due emisferi diversi: ci sono da una parte le header, le intestazioni, che accompagnano la comunicazione contenendo al proprio interno informazioni che la riguardano in quanto a fattori come modalità e tempistiche; dall’altra parte ci sono i dati veri e propri, il message body, quello che realmente percepirà l’utente. In Postman vedremo chiaramente questa suddivisione e capiremo come viene applicato il meccanismo di cache all’interno di una comunicazione HTTP. Le intestazioni sono proprio gli elementi che forniranno le principali indicazioni in materia di caching.

Cache-control: la header principale

La header fondamentale nell’utilizzo della cache HTTP è cache-control. Questa può innanzitutto decretare che i dati scaricati non debbano essere conservati vedendo il suo valore impostato a no-store. Tale situazione dovrebbe verificarsi per dati che cambiano molto di frequente o che contengono informazioni troppo riservate per essere conservate nel browser o cache intermedie. Altro valore che limita l’azione di cache ma non la impedisce del tutto è no-cache che impone di riutilizzare i dati salvati da una risposta precedente esclusivamente previo controllo di aggiornamenti presso il server.

Qualora il server consideri auspicabile il caching dei dati offerti tramite un determinato URL, deve indicare in cache-control almeno due aspetti:

• qual è la visibilità di tali dati: si indica private se solo il client finale può conservarli o public se possono conservarli anche nodi di cache intermedi;
• qual è il tempo di validità dei dati salvati. Si esprime in secondi grazie all’attributo max-age che indica, a partire dalla data di scaricamento, per quanto tempo possono essere usati senza scaricarli nuovamente.

E’ importante specificare due aspetti. In primis, qualora cache-control non fosse presente nella risposta HTTP il caching non è vietato anzi, al contrario, il client può scegliere la politica che preferisce: come è facile immaginare, questa non è una situazione ideale in quanto il client per eseguire correttamente caching delle risposte ha bisogno di chiare indicazioni da parte del server. Altro aspetto da considerare: si trova spesso nelle risposte HTTP l’intestazione Expires che indica fino a quando l’informazione scaricata può essere conservata in cache. Il suo ruolo è analogo a max-age ma si tenga presente che nel protocollo HTTP 1.1 è stato introdotto cache-control come indicazione complessiva per il caching pertanto non necessita di altro, incluso Expires. Vediamo alcuni esempi di quanto detto sinora.

Esempio 1: caching del logo di Google

Le immagini vengono spesso immagazzinate in cache e ciò avviene per almeno un paio di motivi: sono onerose come dimensioni rispetto al testo e cambiano raramente. Tra le immagini che vediamo nei siti Internet una categoria che cambia pochissime volte nel corso di molti anni sono i loghi. Pensiamo al logo di Google, uno dei più famosi del web. Se apriamo l’homepage del motore di ricerca e cerchiamo l’URL dell’immagine otteniamo il seguente indirizzo: https://www.google.it/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png.

Apriamo Postman e facciamo una richiesta GET  all’URL del logo. Quello che segue è la risposta che otteniamo:

Nella sezione Headers della risposta vediamo che ci sono 11 intestazioni. Notiamo cache-control che permette di fare cache in maniera private e fissa come max-age un anno, qui espresso in secondi. Un programma client potrà pertanto immagazzinare l’immagine scaricata e riutilizzarla per un anno al massimo.

Esempio 2: dati finanziari da non mettere in cache

Dal sito Yahoo!Finanza è possibile scaricare in formato CSV dati finanziari aggiornati tramite appositi link. Ad esempio, per scaricare gli ultimi dati sull’indice di Borsa FTSE-MIB si può eseguire una richiesta GET all’indirizzo http://download.finance.yahoo.com/d/quotes.csv?s=FTSEMIB.MI&f=sl1d1t1c1ohgv&e=.csv (lo abbiamo ricavato dal link con etichetta “Scarica dati” in basso a destra nella pagina web relativa all’indice).

Tramite l’analisi offerta da Postman, vediamo che in cache-control ci sono chiare indicazioni di non effettuare cache di questi dati quindi ad ogni richiesta dell’utente essi andranno richiesti nuovamente al server.

Convalida della cache con la data di ultima modifica

Se il client conserva nella propria cache dei dati che andrebbero mostrati di nuovo all’utente ma che sono ormai scaduti, richiedendoli al server rischierebbe di scaricare ancora gli stessi byte. Per un entry scaduta della cache si può chiedere la convalida utilizzando l’ultima data di modifica. Torniamo all’esempio 1 e notiamo che l’ultima modifica al logo di Google (intestazione last-modified) è stata apportata il 4 settembre 2015. Possiamo inviare pertanto una richiesta contenente l’intestazione If-modified-since che indica al server a quale data risale il nostro salvataggio del logo in cache:

Se la data del nostro salvataggio in cache è più recente dell’ultima data del contenuto su server, la risposta conterrà un codice HTTP 304 che significa “Not Modified” ma non l’immagine: ciò vuol dire che possiamo usare il logo che abbiamo in cache. Proviamo a fare un’altra richiesta in cui chiediamo se il logo non è stato modificato dal 2014.

Come possiamo vedere la risposta questa volta non è un codice 304 bensì 200: in pratica il server supponendo che il client conservi in cache un’immagine non più valida ha direttamente offerto in download il logo come si vede dall’intestazione content-length.

Conclusioni

Un discorso simile può sembrare troppo teorico ma in realtà contiene un’estrema valenza pratica. Ogni tecnologia lato client dovrebbe gestire la cache efficacemente per poter offrire migliori prestazioni. Per fortuna, questa funzionalità è già inclusa in molte librerie ma, d’altro canto, i programmatori conoscono poco il funzionamento della cache. Capire i concetti qui esposti è fondamentale per poter usare correttamente il meccanismo ed offrire all’utente sempre prestazioni migliori.

Alla prossima!