Cet article nécessite une relecture technique. Voici comment vous pouvez aider.

Cet article nécessite une relecture rédactionnelle. Voici comment vous pouvez aider.

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

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.

L'utilisation de la fonction de mise en cache d'application décrite ici est actuellement fortement déconseillée; cette fonctioannalité est en train d' être retiré de la plate-forme Web. Utiliser Service Workers à la place. En fait, a 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).

Introduction

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.

Comment fonctionne AppCache

Activer AppCache

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 manifeste spécifie l'URI d'un fichier manifest 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 fichier manifest lui-même. Vous ne devez pas lister toutes les pages que vous souhaitez mettre en cache dans le fichier manifest, 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.

Chargement des documents

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 manifest 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.

The process for loading documents and updating the application cache is specified in greater detail below :

  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 fichier manifest, 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 manifest à 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 fichier manifest 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 manifest 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 fichier manifest a changé, tous les fichiers dans le manifest (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).

Emplacement du stockage et effacement du cache hors-ligne

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 fichier manifest d'une application est retiré du serveur, le navigateur efface toutes les données cachées utilisant ce manifest, et déclenche un event "obsoleted" à l'objet applicationCache. Le statut du cache de l'application est alors OBSOLETE.

Le fichier manifest de cache

Référencement d'un fichier manifest de cache

L'attribut manifest dans une application web peut spécifier le chemin relatif d'un fichier manifest de cache ou une URL absolue. (Les URL absolues doivent être de la même origine que l'application). Un fichier manifest de 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.

Les entrées dans un fichier manifest de cache

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 manifest de cache doivent avoir le même plan, hôte, et port comme un manifest.

Example 1: Un fichier manifest de cache simple

Ci-dessous, un exemple simple de cache manifest — example.appcache utilisé par le site imaginaire www.example.com:

CACHE MANIFEST
# v1 - 2011-08-13
# Ceci est un commentaire.
http://www.example.com/index.html
http://www.example.com/header.png
http://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 manifest 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 fichier manifest 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 manifest lui-même dans le fichier de cache manifest : il vous serait alors quasiment impossible d'informer le navigateur lors de la mise à jour du manifest.

Sections in a cache manifest file: CACHE, NETWORK, and FALLBACK

A manifest can have three distinct sections: CACHE, NETWORK, and FALLBACK.

CACHE:
This is the default section for entries in a cache manifest file. Files listed under the CACHE: section header (or immediately after the CACHE MANIFEST line) are explicitly cached after they're downloaded for the first time.
NETWORK:
Files listed under the NETWORK: section header in the cache manifest file are white-listed resources that require a connection to the server. All requests to such resources bypass the cache, even if the user is offline. The wildcard character * can be used once. Most sites need *.
FALLBACK:
The FALLBACK: section specifies fallback pages the browser should use if a resource is inaccessible. Each entry in this section lists two URIs—the first is the resource, the second is the fallback. Both URIs must be relative and from the same origin as the manifest file. Wildcards may be used.

The CACHE, NETWORK, and FALLBACK sections can be listed in any order in a cache manifest file, and each section can appear more than once in a single manifest.

Example 2: a more complete cache manifest file

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

CACHE MANIFEST
# v1 2011-08-14
# This is another comment
index.html
cache.html
style.css
image1.png

# Fallback content
FALLBACK:
/ fallback.html

# Use from network if available
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.

Structure d'un fichier manifest

Les fichiers manifests 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 manifest, comme défini ici.

Les manifests 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 manifest 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 manifest peut contenir 0 ou plusieurs lignes :

Blank line
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. This also means that you cannot specify fragment identifiers.
Section header
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 cache manifest, et non vers les URI du document qui référence le manifest.

Le cache manifest 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.

Les ressources dans AppCache

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

Master entries
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.
Explicit entries
Il s'agit de ressources listées dans le manifest du cache.
Fallback entries
Il s'agit de ressources listées dans le manifest 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.

Resource categories are described in greater detail below.

Master entries

Tous les fichiers HTML peuvent inclure un attribut manifest dans leur élément <html>. Par exemple, disons que nous avons le fichier http://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 manifest, visiter la page entry.html provoquera l'ajout de la page entry.html dans le cache de l'application comme une master entry.

Explicit entries

Les entrées explicites sont des ressources explicitement listées dans la section CACHE d'un fichier manifest de cache.

Network entries

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 http://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 manifest n'aurait pas le même comportement parce que les master entries seront ajoutées — et donc servies depuis— le cache. 

Fallback entries

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 fichier manifest situé à http://www.example.com/example.appcache, et qui contient :

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

Toute requête vers http://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.

Les états

Chaque cache a un statut qui indique la condition actuelle du cache. Les caches qui partagent la même URI de manifest 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 manifest 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 manifest.
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.

Testing for updates to the cache manifest

Vous pouvez programmer un test pour voir si une application possède un fichier manifest de cache à jour en utilisant JavaScript. Depuis un fichier manifest 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() {
  alert('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
  onUpdateReady();
}

Pour démarrer manuellement le test pour un nouveau fichier manifest de cache, vous pouvez utilisez window.applicationCache.update().

Gotchas

  • Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network. To link to cached resources that have parameters parsed in JavaScript use parameters in the hash part of the link, such as other-cached-page.html#whatever?parameterName=value.
  • When applications are cached, simply updating the resources (files) that are used in a web page is not enough to update the files that have been cached. You must update the cache manifest file itself before the browser retrieves and uses the updated files. You can do this programmatically using window.applicationCache.swapCache(), though resources that have already been loaded will not be affected. To make sure that resources are loaded from a new version of the application cache, refreshing the page is ideal.
  • It's a good idea to set expires headers on your web server for *.appcache files to expire immediately. This avoids the risk of caching manifest files. For example, in Apache you can specify such a configuration as follows:
    ExpiresByType text/cache-manifest "access plus 0 seconds"

Compatibilité des navigateurs

Navigateur Chrome Firefox (Gecko) Internet Explorer Opera Safari
Version supportée 4.0 3.5 10.0 10.6 4.0
Navigateur Android Firefox Mobile (Gecko) IE Mobile Opera Mobile Safari Mobile
Version supportée 2.1 (Oui) 11.0 11.0 3.2

 

Voir aussi

 

Étiquettes et contributeurs liés au document

 Dernière mise à jour par : personnel,