--- title: Utilizzare l'application cache slug: Web/HTML/utilizzare_application_cache translation_of: Web/HTML/Using_the_application_cache ---
HTML5 possiede un meccanismo di application caching che permette alle applicazioni web-based di funzionare anche offline. Gli sviluppatori possono utilizzare l'interfaccia Application Cache (AppCache) per specificare le risorse che il browser deve memorizzare nella cache e rendere disponibili per gli utenti offline. Le applicazioni in cache si caricano e funzionano correttamente anche se gli utenti cliccano sul tasto refresh del browser quando sono offline.
L'uso dell'application cache fornisce all'applicazione i seguenti benefici:
Per abilitare l'application cache per un'applicazione, è necessario includere l'attributo {{htmlattrxref("manifest", "html")}} nell'elemento {{HTMLElement("html")}} delle pagine della tua applicazione, come mostrato nel seguente esempio:
L'attributo manifest
fa riferimento ad un cache manifest, un file di testo che elenca tutte le risorse (files) che il browser deve memorizzare per la tua applicazione.
Bisogna includere l'attributo manifest
in tutte le pagine dell'applicazione che vuoi memorizzare nella cache, il browser non memorizza le pagine che non contengono l'attributo manifest
, a meno che tali pagine siano esplicitamente elencate nel file manifest stesso. Non c'è bisogno di elencare nel cache manifest tutte le pagine che si vogliono memorizzare nella cache, il browser implicitamente aggiunge ogni pagina che l'utente visita e che ha l'attributo manifest
settato sull'application cache.
Alcuni browser (es. Firefox) mostrano una barra di notifica la prima volta che un utente carica un'applicazione che usa l'application cache. La barra di notifica mostra un messaggio tipo:
Questo sito web (www.example.com
) richiede di salvare dati sul computer per l'utilizzo non in linea. [Permetti] [Mai per questo sito] [Non adesso]
Il termine "offline(-enabled) applications" qualche volta fa riferimento alle applicazioni che l'utente ha esplicitamente abilitato ad utilizzare le capacità offline.
L'uso dell'application cache modifica il normale processo di caricamento del documento:
Il processo di caricamento del documento ed aggiornamento dell'application cache è specificato in maggior dettaglio qui sotto:
manifest
, se non esiste un application cache, il browser carica il documento e poi va a prendere tutte le risorse elencate nel file manifest, creando la prima versione dell'application cache.checking
all'oggetto window.applicationCache
e processa il file manifest, seguendo le appropriate regole di chaching HTTP. noupdate
all'oggetto applicationCache
, ed il processo di aggiornamento è completo. Da notare che se viene modificata una qualsiasi delle risorse sul server, bisogna modificare anche il file manifest, in maniera tale che il browser sappia che ha bisogno di processare tutte le risorse nuovamente.applicationCache.add()
- sono aggiunti ad una cache temporanea, seguendo le appropriate regole di caching HTTP. Per ogni file memorizzato in questa cache temporanea, il browser invia un evento progress
all'oggetto applicationCache
. In caso di errore, il browser invia un evento error
e blocca l'aggiornamento dell'application cache.cached
all'oggetto applicationCache
. Dato che il documento è stato già caricato nel browser prelevandolo dalla cache, il documento aggiornato non sarà renderizzato finchè non viene ricaricato (manualmente o attraverso la programmazione).Su Chrome è possibile cancellare la cache offline sia selezionando "Clear browsing data..." dalle preferenze, oppure visitando chrome://appcache-internals/. Safari ha una voce "Svuota cache" simile nelle sue preferenze, ma potrebbe essere necessario riavviare il browser.
Su Firefox, i dati della cache offline vengono memorizzati separatamente dal profilo Firefox — insieme ai dati degli altri programmi installati:
C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<profile name>\OfflineCache
/Users/<username>/Library/Caches/Firefox/Profiles/<salt>.<profile name>/OfflineCache
Su Firefox è possibile ispezionare lo stato della cache offline sulla pagina about:cache
(box "Offline cache device"). La cache offline può essere cancellata separatamente per ogni sito utilizzando il tasto "Rimuovi..." presente in:
Firefox -> Opzioni -> Avanzate -> Rete -> Dati non in linea e informazioni utente.
Nelle versioni precedenti a Firefox 11, l'application cache non poteva essere cancellata utilizzando
Tools -> Clear Recent History
oppure
Tools -> Options -> Advanced -> Network -> Offline data -> Clear Now Questo bug è stato fixato nelle versioni successive.
Vedi anche clearing the DOM Storage data.
Le application cache possono anche diventare obsolete. Se il un file manifest dell'applicazione viene rimosso dal server, il browser rimuove tutte le application cache che utilizzano quel manifest ed invia un evento "obsoleted" all'oggetto applicationCache
. Questo imposta lo stato dell'application cache su OBSOLETE
.
L'attributo manifest
in un'applicazione web può specificare sia il percorso relativo di un file cache manifest che un URL assoluto (gli URL assoluti devono provenire dalla stessa origine dell'applicazione). Un file cache manifest può avere diverse estensioni, ma come MIME type deve avere text/cache-manifest
.
AddType text/cache-manifest .appcache
ad un file .htaccess posizionato nella cartella root, oppure nella stessa cartella dell'applicazione.Il cache manifest è un semplice file di testo che elenca le risorse che il browser deve memorizzare per l'accesso offline. Le risorse sono identificate da un URI. Le voci elencate nel cache manifest devono avere lo stesso schema, host e porta come nel manifest.
Il seguente è un semplice file di cache manifest, example.appcache
, per un ipotetico sito web all'indirizzo www.example.com.
CACHE MANIFEST # v1 - 2011-08-13 # This is a comment. http://www.example.com/index.html http://www.example.com/header.png http://www.example.com/blah/blah
Un file cache manifest può includere 3 sezioni (CACHE
, NETWORK
, e FALLBACK
, verranno discusse in seguito). Nell'esempio qui sopra, non c'è una sezione header, quindi si assume che tutte le risorse siano elencate nell'esplicita sezione (CACHE
), intendendo che il browser deve memorizzare nell'application cache tutte le risorse elencate. Le risorse possono essere specificate utilizzando sia URL assoluti che relativi (es. index.html
).
Il commento "v1" si trova lì per una buona ragione. I browser aggiornano l'application cache solo se il file manifest viene modificato. Se una risorsa presente nella cache viene modificata (per esempio, viene aggiornata l'immagine header.png
con un nuovo contenuto), bisogna anche cambiare il contenuto del file manifest per permettere ai browser di sapere che c'è bisogno di refreshare la cache. Si può effettuare qualsiasi modifica al file manifest, ma la best practice è modificare il numero di versione.
CACHE
, NETWORK
, e FALLBACK
Un manifest può avere 3 sezioni distine: CACHE
, NETWORK
, e FALLBACK
.
CACHE:
CACHE:
(oppure subito dopo la riga CACHE MANIFEST
) sono esplicitamente memorizzati nella cache dopo che vengono scaricati per la prima volta.NETWORK:
NETWORK:
sono risorse inserite in una white-list che richiedono una connessione al server. Tutte le richieste a queste risorse bypassano la cache, anche se l'utente è offline. È possibile utilizzare wildcards.FALLBACK:
FALLBACK:
vengono specificate le pagine alternative che il browser deve utilizzare nel caso una risorsa non sia accessibile. Ogni voce in questa sezione è composta da 2 URI - il primo è la risorsa, il secondo il fallback. Entrambi gli URI devono essere relativi e provenienti dalla stessa origine del file manifest. È possibile utilizzare wildcards.Le sezioni CACHE
, NETWORK
, e FALLBACK
possono essere elencate in qualsiasi ordine, ogni sezione può apparire più volte nello stesso cache manifest.
Il seguente è un esempio più completo di un cache manifest per un ipotetico sito web all'indirizzo www.example.com.
CACHE MANIFEST # v1 2011-08-14 # This is another comment index.html cache.html style.css image1.png # Use from network if available NETWORK: network.html # Fallback content FALLBACK: / fallback.html
Questo esempio utilizza le sezioni NETWORK
e FALLBACK
per specificare che la pagina network.html
deve essere sempre prelevata dalla rete e che la pagina fallback.html
deve essere servita nel caso una risorsa non sia disponibile (es. nel caso sia impossibile stabilire una connessione col server).
Un cache manifest deve essere servito con il MIME type text/cache-manifest
. Tutte le risorse servite utilizzando questo MIME type devono seguire la sintassi per l'application cache manifest, come definito in questa sezione.
I cache manifest sono file di testo in formato UTF-8 e possono opzionalmente contenere un carattere BOM. Gli a capo possono essere rappresentati dal line feed (U+000A
), dal carriage return (U+000D
), o da entrambi i caratteri.
La prima riga del cache manifest deve obbligatoriamente essere la stringa CACHE MANIFEST
(con un singolo spazio U+0020
tra le due parole), seguita da zero o pià caratteri di tabulazione. Qualsiasi altro testo su questa riga verrà ignorato.
Il resto del manifesto cache deve essere composto da zero o più delle seguenti righe:
Header di sezione Descrizione CACHE:
Sezione che definisce quali risorse memorizzare nella cache (questa è la sezione di default, se l'header non è specificato). NETWORK:
Sezione che definisce quali risorse devono essere sempre scaricate dalla rete. FALLBACK:
Sezione che definisce dei fallback nel caso una risorsa risulti non disponibile.
CACHE:
), ogni riga è un riferimento URI o IRI valido ad una risorsa da memorizzare nella cache (non è possibile utilizzare caretteri jolly in queste sezioni). Si possono inserire spazi vuoti prima o dopo l'URI o l'IRI. Nella sezione di fallback ogni riga è un riferimento URI o IRI valido ad una risorsa, seguito dalla risorsa di fallback che deve essere servita qualndo non si può stabilire una connessione col server. nella sezione network, ogni riga è un riferimento URI o IRI valido ad una risorsa da prelevare dalla rete. (In questa sezione è consentito utilizzare il carattere jolly *).
I file cache manifest possono passare da una sezione all'altra a piacimento (ogni header di sezione può essere utilizzato più di una volta), le sezioni possono anche essere vuote.
Un application cache include sempre almeno una risorsa, identificata da un URI. Tutte le risorse rientrano in una delle seguenti categorie:
manifest
.Le categorie di risorse sono descritte in dettaglio qui di seguito.
Le master entries sono un qualsiasi file HTML che include l'attributo {{htmlattrxref("manifest","html")}} nell'elemento {{HTMLElement("html")}}. Per esempio, diciamo che abbiamo il file HTML http://www.example.com/entry.html
, composto in questa maniera:
<html manifest="example.appcache"> <h1>Application Cache Example</h1> </html>
se entry.html
non è elencato nel file cache manifest example.appcache
, basta visitare la pagina per farla aggiungere all'application cache in qualità di master entry.
Le Explicit entries sono le risorse esplicitamente elencate in una sezione CACHE
del file cache manifest.
La sezione NETWORK
di un cache manifest, specifica le risorse dell'applicazione web che richiedono l'accesso online. Queste voci sono essenzialmente una "online whitelist" — le URI specificate nella sezione NETWORK
sono sempre caricate dal server invece che dalla cache. In questo modo il modello di sicurezza del browser protegge l'utente da potenziali falle di sicurezza limitando l'accesso alle risorse approvate.
Per esempio, si può utilizzare la lista delle risorse network per caricare ed eseguire script ed altro codice dal server invece che dalla cache:
CACHE MANIFEST NETWORK: /api
La sezione del cache manifest mostrata qui sopra assicura che tutte le richieste di files contenuti nella sottocartella http://www.example.com/api/
vengano sempre caricate dalla rete senza accedere alla cache.
manifest
nell'elemento html
) dal file manifest potrebbe non avere lo stesso risultato, perchè le master entries sarebbero scaricate solo la prima volta dalla rete, per poi essere aggiunte e prelevate dalla cache ai successivi accessi.Fallback entries sono utilizzate quando fallisce il tentativo di caricare una risorsa. Per esempio, diciamo che il cache manifest http://www.example.com/example.appcache
includa il seguente contenuto:
CACHE MANIFEST FALLBACK: example/bar/ example.html
Qualsiasi richiesta a http://www.example.com/example/bar/
o a una qualsiasi delle sue sottocartelle ed il loro contenuto fa partire una richiesta newtwork per caricare la risorsa richiesta. Se il tentativo fallisce, a causa della connessione o di un qualsiasi errore del server, il browser carica il file example.html
al suo posto.
Ogni application cache possiede uno stato, che indica la condizione corrente della cache. Le cache che condividono la stessa URI per il manifest, condividono anche lo stesso stato della cache, che può essere uno dei seguenti:
UNCACHED
IDLE
CHECKING
DOWNLOADING
UPDATEREADY
updateready
, che è lanciato al posto dell'evento cached
quando un nuovo aggiornamento è stato scaricato ma non ancora attivato tramite il metodo swapCache()
.OBSOLETE
Si può effettuare, attraverso JavaScript, un test per vedere se un'applicazione ha il cache manifest aggiornato. Dato che un cache manifest può essere stato aggiornato prima che uno script venga caricato ed attacchi un event listener per controllare gli aggiornamenti, gli script devono sempre utilizzare il test window.applicationCache.status
.
function onUpdateReady() { alert('found new version!'); } window.applicationCache.addEventListener('updateready', onUpdateReady); if(window.applicationCache.status === window.applicationCache.UPDATEREADY) { onUpdateReady(); }
Per testare manualmente un nuovo file manifest, è possibile utilizzare window.applicationCache.update()
.
other-cached-page.html?parameterName=value
). In questo modo il browser ignorerà la cache e andrà a prendere il file dalla rete. Per linkare risorse nella cache che hanno parametri parsati in Javascript, utilizzare i parametri dopo l'hash (#), come per esempio: other-cached-page.html#whatever?parameterName=value
.window.applicationCache.swapCache()
, anche se le risorse che sono state già caricate non saranno interessate. Per assicurarsi che le risorse vengono caricate da una nuova versione della cache dell'applicazione, ricaricare la pagina è l'ideale.*.appcache
scadano immediatamente. Questo evita il rischio di inserire nella cache il cache manifest stesso. Per esempio, su Apache è possibile impostare questo comportamento nella seguente:ExpiresByType text/cache-manifest "access plus 0 seconds"
{{CompatibilityTable}}
Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari |
---|---|---|---|---|---|
Basic support | 4.0 | 3.5 | 10.0 | 10.6 | 4.0 |
Feature | Android | Firefox Mobile (Gecko) | IE Mobile | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|
Basic support | 2.1 | {{CompatVersionUnknown}} | {{CompatNo}} | 11.0 | 3.2 |
Nota: Le versioni di Firefox precedenti alla 3.5 ignorano le sezioni NETWORK
e FALLBACK
del file cache manifest.