Utiliser Application Cache

Contexte sécurisé
Cette fonctionnalité est uniquement disponible dans des contextes sécurisés (HTTPS), pour certains navigateurs qui la prennent en charge.

Obsolète
Cette fonctionnalité a été supprimée des standards du Web. Bien que quelques navigateurs puissent encore la supporter, elle est en cours d'éradication. Ne l'utilisez ni dans d'anciens projets, ni dans de nouveaux. Les pages et applications Web l'utilisant peuvent cesser de fonctionner à tout moment.

Attention ! L'utilisation de la fonction de mise en cache d'application d√©crite ici est actuellement fortement d√©conseill√©e; cette fonctionnalit√© est en train d' √™tre retir√© de la plate-forme Web. Utiliser Service Workers √† la place. En fait, √† partir de Firefox 44, quand l'application cache est utilis√© pour fournir une aide hors ligne pour une page, un message d'avertissement est maintenant affich√© dans la console conseillant aux d√©veloppeurs d'utiliser Service workers √† la place (bug 1204581).

BCD tables only load in the browser

HTML5 supporte la mise en cache hors-ligne de ressources d'applications web; les fichiers sont stock√©s dans l'Application Cache (AppCache) - une collection de ressources obtenues depuis un fichier manifest (*.appcache) inclue dans une application web.

L'utilisation d'une application cache permet les bénéfices suivants :

  • Navigation hors-ligne : les utilisateurs peuvent utiliser un site m√™me s'ils ne sont pas connect√©s.
  • Vitesse : les ressources mises en cache sont locales, et se chargent donc plus rapidement.
  • R√©duction de la charge serveur : le navigateur ne t√©l√©charge uniquement les ressources qui ont chang√©es sur le serveur.

Vous devez, pour utiliser le cache d'application, utiliser l'attribut manifest dans l'√©l√©ment <html> comme suit :

<html manifest="example.appcache">
  ...
</html>

L'attribut manifest spécifie l'URI d'un manifeste de cache, qui est un fichier texte qui répertorie les ressources (fichiers) que le navigateur doit mettre en cache pour votre application.

Vous devez inclure l'attribut manifest sur chaque page de votre application que vous souhaitez mettre en cache. Le navigateur met pas en cache les pages qui ne contiennent pas l'attribut manifest, sauf si celle-ci sont explicitement mentionn√©es dans le manifeste m√™me. Vous ne devez pas lister toutes les pages que vous souhaitez mettre en cache dans le fichier manifeste, le navigateur ajoute implicitement chaque page que l'utilisateur visite et qui poss√®de l'attribut manifest r√©gl√© sur le cache de l'application.

Certains navigateurs dont Firefox vont avertir l'utilisateur la première fois que celui-ci charge votre application par une notification :

¬ę Ce site internet (www.example.com) veut stocker des donn√©es sur votre ordinateur pour une utilisation hors-ligne. [Accepter] [Refuser pour ce site] [Pas maintenant] ¬Ľ.

Le terme ¬ę d'applications (fonctionnant) hors-ligne ¬Ľ est parfois utilis√© pour d√©signer les applications que l'utilisateur a autoris√© √† travailler hors-ligne.

L'utilisation d'un cache de l'application modifie le processus normal de chargement d'un document :

  • Si un cache de l'application existe, le navigateur charge le document et ses ressources associ√©es directement √† partir de la m√©moire cache, sans acc√©der au r√©seau. Cela acc√©l√®re le temps de chargement du document.
  • Le navigateur v√©rifie ensuite si le manifeste de cache a √©t√© mis √† jour sur le serveur.
  • Si le manifeste de cache a √©t√© mis √† jour, le navigateur t√©l√©charge une nouvelle version du manifeste et les ressources figurant dans  ce dernier. Cela se fait en arri√®re-plan et n'affecte pas les performances de mani√®re significative.

Le proc√©d√© de chargement de documents et mise √† jour du cache de l'application est d√©finie de mani√®re plus d√©taill√©e ci-dessous:

  1. Quand le navigateur visite un document qui contient l'attribut manifest et qu'il n'existe pas encore de cache d'application, il chargera le document puis récupérera toutes les entrées listées dans le manifeste, créant ainsi la première version du cache d'application.
  2. Lors des visites ult√©rieures de ce document, le navigateur chargera le document et les autres ressources pr√©cis√©es dans le manifeste √† partir du cache d'application ‚ÄĒ et non du serveur. De plus, le navigateur enverra aussi un √©v√®nement checking √† l'objet window.applicationCache, puis r√©cup√®re le manifeste en fonction de la r√®gle de cache HTTP ad√©quate.
  3. Si la version en cache du manifeste est à jour, l'évènement noupdate est envoyé a l'applicationCache, et le processus de mise à jour est terminé. C'est la raison pour laquelle vous devez changer le manifeste chaque fois que vous mettez à jour les ressources sur le serveur, afin que le navigateur sache qu'il doit de nouveau récupérer les ressources.
  4. Si le manifeste a changé, tous les fichiers dans le manifeste (dont ceux ajoutés au cache lors de l'appel à applicationCache.add()) sont récupérés dans un cache temporaire, en fonction des règles de cache HTTP adéquates. Un évènement progress est envoyé à l'objet applicationCache chaque fois qu'un fichier est récupéré dans le cache temporaire. Un évènement error est envoyé à chaque erreur, et la mise à jour s'arrête.
  5. Une fois tous les fichiers récupérés en bonne et due forme, ils sont transférés dans le véritable cache hors-ligne un par un, et un évènement cached est envoyé à l'objet applicationCache. Le document étant déjà chargé dans le navigateur depuis le cache, le document mis à jour ne sera pas ré-affiché tant que celui-ci n'est pas chargé à nouveau (que ce soit manuellement ou via un programme).

Dans Chrome, le cache hors-ligne peut √™tre effac√© gr√Ęce au bouton "Effacer les donn√©es de navigation..." dans les pr√©f√©rences, ou en ouvrant chrome://appcache-internals/. Safari a un param√®tre "Vider le cache" dans ses pr√©f√©rences, mais il est possible que le red√©marrage du navigateur soit n√©cessaire.

Dans Firefox, les donn√©es de cache hors-ligne sont stock√©es s√©par√©ment du profil Firefox‚ÄĒ√† c√īt√© du cache disque normal :

  • Windows Vista/7: C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<profile name>\OfflineCache
  • Mac/Linux: /Users/<username>/Library/Caches/Firefox/Profiles/<salt>.<profile name>/OfflineCache

Dans Firefox l'√©tat actuel du cache hors-ligne est consultable sur la page about:cache (dans la section "Offline cache device"). Le cache hors-ligne peut √™tre effac√© pour chaque site individuellement √† l'aide du boutton "Supprimer..." dans  Menu -> Options -> Avanc√© -> R√©seau -> Contenu web et donn√©es utilisateur hors connexion.

Avant Firefox 11, ni Tools -> Clear Recent History ni Tools -> Options -> Advanced -> Network -> Offline data -> Clear Now ne permettaient d'effacer le cache hors-ligne. Ceci a été corrigé.

Voir aussi effacer les donn√©es de stockage DOM.

Les caches d'application peuvent aussi devenir obsolètes. Si le manifeste d'une application est retiré du serveur, le navigateur efface toutes les données cachées utilisant ce manifeste, et déclenche un event "obsoleted" à l'objet applicationCache. Le statut du cache de l'application est alors OBSOLETE.

L'attribut manifest dans une application web peut sp√©cifier le chemin relatif d'un manifeste de cache ou une URL absolue. (Les URL absolues doivent √™tre de la m√™me origine que l'application). Le manifeste du cache peut avoir une extension de fichier, mais il doit √™tre servi avec le MIME type text/cache-manifest.

Note: Sur les serveurs Apache, le MIME type pour les fichiers manifest (.appcache) peut √™tre d√©fini par l'ajout de AddType text/cache-manifest .appcache √† un fichier a .htaccess soit √† l'int√©rieur du r√©pertoire racine, soit le m√™me r√©pertoire que l'application.

Le fichier manifest de cache est un simple fichier de texte qui liste les ressources que le navigateur doit cache pour l'acc√®s hors ligne. Les ressources sont identifi√©es par URI. Les entr√©es list√©es dans le manifeste de cache doivent avoir le m√™me plan, h√īte, et port comme un manifest.

Ci-dessous, un exemple simple de manifeste ‚ÄĒ example.appcache utilis√© par le site imaginaire www.example.com:

CACHE MANIFEST
# v1 - 2011-08-13
# Ceci est un commentaire.
https://www.example.com/index.html
https://www.example.com/header.png
https://www.example.com/blah/blah

Il n'y a pas, dans cet exemple, d'en-tête de section, donc toutes les lignes sont supposées être des sections (CACHE:) explicites. On peut aussi utiliser des URL relatives (index.html, …)

Le commentaire ¬ę v1 ¬Ľ n'est pas l√† par hasard : le cache n'est mis √† jour que quand le manifeste change, avec une correspondance d'octet √† octet. Si vous utilisez d'autres ressources (par exemple en mettant √† jour le contenu de l'image header.png), vous devez changer le manifeste pour signaller au navigateur qu'il doit rafra√ģchir le cache, et, comme header.png est d√©j√† pr√©sent dans le cache, vous devez modifier quelquechose d'autre. Bien que vous puissiez changer n'importe quoi d'autre dans le manifest, utiliser un num√©ro de version est une bonne pratique conseill√©e.

Important: N'utilisez pas le manifeste lui-même dans le fichier de manifeste : il vous serait alors quasiment impossible d'informer le navigateur lors de la mise à jour du manifeste.

Un manifeste peut avoir trois sections distinctes: CACHE, NETWORK, et FALLBACK.

CACHE:
Ceci est la section par d√©faut pour les entr√©es dans un manifeste de cache. Les fichiers sont r√©pertori√©s sous le CACHE: l'en-t√™te de section (ou imm√©diatement apr√®s la ligne MANIFESTE CACHE) est explicitement mis en cache apr√®s qu'il ait √©t√© t√©l√©charg√© pour la premi√®re fois.
NETWORK:
Les fichiers r√©pertori√©s dans le NETWORK: l'en-t√™te de section dans le fichier manifeste de cache est une ressource de la liste blanche qui n√©cessite une connexion au serveur. Toutes les demandes √† cette ressource contournent le cache, m√™me si l'utilisateur est d√©connect√©. Le caract√®re g√©n√©rique * peut √™tre utilis√© qu'une seule fois. La plupart des sites en ont besoin *.
FALLBACK:
Le FALLBACK: section qui sp√©cifie les pages de repli que le navigateur doit utiliser si une ressource est inaccessible. Chaque entr√©e dans cette section r√©pertorie deux URIs (le premier est la ressource, le second est le repli). Les deux URIs doivent √™tre relatif et de la m√™me origine que le fichier manifeste. Les Wildcards peuvent √™tre utilis√©s.

Les sections CACHE, NETWORK, et FALLBACK peuvent √™tre list√©s dans n'importe  quel ordre dans un manifeste de cache, et chaque section peut appara√ģtre plus qu'une fois dans un simple manifeste.

Voici un exemple plus complet de manifeste pour notre site imaginaire www.example.com.

CACHE MANIFEST
# v1 2011-08-14
# Ceci est un autre commentaire
index.html
cache.html
style.css
image1.png

# Contenu Fallback
FALLBACK:
. fallback.html

# L'utilise depuis le network (réseau) si il est disponible
NETWORK:
network.html

Nous utilisons dans cet exemple les sections FALLBACK et NETWORK pour préciser que la page network.html doit toujours être récupérée depuis le réseau et que la page fallback.html doit être utilisée comme ressource de secours, par exemple si la connexion au serveur ne peut être établie.

Les manifestes doivent √™tre servis avec le type MIME text/cache-manifest, et toutes les ressources servies en utilisant ce type MIME doivent respecter la syntaxe d'un manifeste, comme d√©fini ici.

Les manifestes sont des fichiers textes au format UTF-8 et peuvent, éventuellement, inclure un caractère BOM. Les nouvelles lignes peuvent être représentés par saut de ligne (U+000A), retour chariot (U+000D), ou les deux.

La premi√®re ligne du manifeste doit √™tre la chaine CACHE MANIFEST (s√©par√© par un simple espace U+0020), suivi par aucun ou plusieurs espaces ou tabulations. Tout autre texte sur la ligne sera ignor√©.

Le reste du manifeste peut contenir 0 ou plusieurs lignes :

Lines vides
Vous pouvez utiliser les lignes vides comprenant 0 ou plusieurs espaces ou tabulations.
Commentaire
Les commentaires consistent en 0 ou plusieurs espaces ou tabulations suivis du caract√®re #, suivi de 0 ou plusieurs caract√®res de texte. Les commentaires devraient √™tre utilis√©s seulement sur leur propre ligne, et ne devrait pas √™tre ajout√©s √† d'autres lignes. Cela signifie √©galement que vous ne pouvez pas sp√©cifier les identifiants de fragments.
Section de tête
La section header précise la section du cache qui est manipulée. Il en existe trois types:
Section header Description
CACHE: Passe à la section explicite. C'est la section par défaut.
NETWORK: Passe à la section des sections en ligne sur la liste blanche.
FALLBACK: Passe à la section de secours.
La ligne d'en-t√™te de section peut contenir des espaces, mais doit inclure un ¬ę : ¬Ľ dans le nom de la section.
Section data
Le format des lignes de donn√©es varie selon les sections. Dans la section explicite (CACHE:) chaque ligne contient une r√©f√©rence URI ou IRI √† une ressource en cache (aucun caract√®re joker n'est admis dans cette section). Des espaces sont accept√© avant et apr√®s l'URI on l'IRI sur chaque ligne. Dans la section de secours, chaque ligne est une r√©f√©rence URI ou IRI vers une ressource, suivie d'une ressource de secours qui sera utilis√©e lorsque la connexion au serveur ne peut √™tre √©tablie. Dans la section en ligne, chaque ligne est une r√©f√©rence valide URI ou IRI √† une ressource qui sera r√©cup√©r√©e sur le r√©seau (le caract√®re joker ¬ę * ¬Ľ est autoris√© dans cette section).
Note: Les URI relatives pointent vers les URI du manifeste, et non vers les URI du document qui référence le manifeste.

Le manifeste peut passer à l'envie d'une section à l'autre (chaque en-tête de section peut être utilisée plusieurs fois), et les sections vides sont tolérées.

Le cache inclue toujours au moins une ressource, identifi√©e par URI. Toutes les ressources r√©pondent √† une des cat√©gories suivantes :

Entrées Maitres
Il s'agit de ressources ajout√©es au cache parce qu'un contexte de navigation visit√© par l'utilisateur incluait un document qui indiquait que ces ressources √©taient dans le cache en utilisant son attribut manifest.
Entrées Explicites
Il s'agit de ressources listées dans le manifeste du cache.
Entrées Network
Il s'agit de ressources listées dans le manifeste du cache comme entrées de network.
Entrées Fallback
Il s'agit de ressources listées dans le manifeste du cache comme entrées de fallback.
Note : Les ressources peuvent être marquées dans plusieurs catégories, et peuvent donc être catégorisées comme des entrées multiples. Par exemple, une entrée peut être à la fois une entrée explicite et une entrée de fallback.

Les catégories ressources sont décrites en détail ci-dessous.

Tous les fichiers HTML peuvent inclure un attribut manifest dans leur √©l√©ment <html>. Par exemple, disons que nous avons le fichier https://www.example.com/entry.html, qui ressemble √† √ßa :

<html manifest="example.appcache">
  <h1>Application Cache Example</h1>
</html>

Si entry.html n'est pas inclue dans le manifeste, visiter la page entry.html provoquera l'ajout de la page entry.html dans le cache de l'application comme une master entry.

Les entr√©es explicites sont des ressources explicitement list√©es dans la section CACHE d'un manifeste de cache.

Les entr√©es list√©es dans NETWORK : peuvent contenir plusieurs ou aucune ressource que l'application requiert lors d'un acc√®s en ligne. C'est principalement une liste blanche en ligne. Les URIS sp√©cifi√©es dans la section NETWORK sont charg√©es depuis le serveur plut√īt que depuis le cache. Cela permet au mod√®le de s√©curit√© du navigateur de prot√©ger l'utilisateur de possibles br√®ches de s√©curit√© en limitant l'acc√®s aux seules ressources approuv√©es.

Note : La liste blanche en ligne est ignor√©e pour les versions de Firefox ant√©rieures √† 3.5.

Vous pouvez l'utiliser pour, par exemple, charger et exécuter des scripts et d'autres codes depuis le serveur au lieu du cache. :

CACHE MANIFEST
NETWORK:
/api

Ceci assure que les requ√™tes t√©l√©chargent les ressources contenues dans https://www.example.com/api/ viendront toujours du r√©seau sans essayer d'acc√©der au cache.

Note : Juste omettre les master entries (les fichiers qui ont l'attribut manifest d√©fini dans l'√©l√©ment html) dans le manifeste n'aurait pas le m√™me comportement parce que les master entries seront ajout√©es ‚ÄĒ et donc servies depuis‚ÄĒ le cache. 

Les entrées de fallback sont utilisées quand une tentative de chargement d'une ressource échoue. Par exemple, imaginons qu'il y a un manifeste situé à https://www.example.com/example.appcache, et qui contient :

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

Toute requ√™te vers https://www.example.com/example/bar/ ou n'importe lequel de ses sous-r√©pertoires et contenus provoquera une tentative de chargement de la ressource demand√©e. Si la tentative √©choue, soit √† cause d'un √©chec r√©seau ou d'une erreur serveur quelle qu'elle soit, le contenu du fichier example.html sera charg√© √† la place.

Chaque cache a un statut qui indique la condition actuelle du cache. Les caches qui partagent la m√™me URI de manifeste partagent le m√™me statut, qui est un des suivants :

UNCACHED
Une valeur sp√©ciale qui indique qu'un object application cache n'est pas compl√®tement initialis√©e.
IDLE
Le cache n'est pas en cours de mise à jour.
CHECKING
Le manifeste est en train d'√™tre contr√īl√© pour d'√©ventuelles mises √† jour.
DOWNLOADING
Des ressources sont en train d'√™tre t√©l√©charg√©es pour √™tre ajout√©es au cache, d√Ľ √† un changement du manifeste.
UPDATEREADY
Il y a une nouvelle version du cache disponible. Il y a un √©v√®nement updateready correspondant, qui est lanc√© au lieu de l'√©v√®nement cached quand une nouvelle mise √† jour a √©t√© t√©l√©charg√©e mais pas encore activ√©e via la m√©thode swapCache().
OBSOLETE
Le groupe de caches est maintenant obsolète.

Vous pouvez programmer un test pour voir si une application poss√®de un manifeste de cache √† jour en utilisant JavaScript. Depuis un manifeste de cache peut √™tre √©t√© mis √† jour avant un script qui teste si les √©v√©nements sont √† jour, les scripts doivent toujours tester window.applicationCache.status.

function onUpdateReady() {
  console.log('nouvelle version trouvée !');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
  onUpdateReady();
}

Pour d√©marrer manuellement le test pour un nouveau manifeste de cache, vous pouvez utilisez window.applicationCache.update().

  • Ne jamais acc√©der √† des fichiers mis en cache √† l'aide des param√®tres GET traditionnels (comme other-cached-page.html?parameterName=value). Cela rendra le contournement du navigateur du cache et de tenter de l'obtenir √† partir du r√©seau. Pour cr√©er un lien vers les ressources mises en cache qui ont des param√®tres analys√©s dans les param√®tres d'utilisation de JavaScript dans la partie de hach de la liaison, comme other-cached-page.html#whatever?parameterName=value.
  • Lorsque les applications sont mises en cache, mettant simplement √† jour les ressources (fichiers) qui sont utilis√©s dans une page Web mais cela ne suffit pas √† mettre √† jour les fichiers qui ont √©t√© mis en cache. Vous devez mettre √† jour le fichier manifeste de cache lui-m√™me avant que le navigateur r√©cup√®re et utilise les fichiers mis √† jour. Vous pouvez le faire par programmewindow.applicationCache.swapCache(), si les ressources qui ont d√©j√† √©t√© charg√©es ne seront pas affect√©s. Pour vous assurer que les ressources sont charg√©es √† partir d'une nouvelle version du cache de l'application, rafra√ģchir la page est id√©al.
  • Il est une bonne id√©e de mettre des en-t√™tes expir√©s sur votre serveur web pour les fichiers * .appcache pour qu'ils expirent imm√©diatement. Cela √©vite le risque de mise en cache des fichiers manifestes. Par exemple, dans Apache, vous pouvez sp√©cifier une telle configuration comme suit:
    ExpiresByType text/cache-manifest "access plus 0 seconds"