Vos résultats de recherche

    Ressources hors ligne dans Firefox

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

    AppCache

    Chaque manifest d'une application web a son propre cache. Depuis que les applications peuvent partager des ressources (et même la même URI de manifest), chaque cache d'une application a une copie séparée de toutes les ressources. Ces caches sont versionnés; à chaque fois que l'application web est visitée en étant connecté, une nouvelle version de l'application peut être synchronisée dans application cache si des mises à jour sont disponibles. Cette nouvelle version sera ensuite utilisée à la prochaine visite.

    Comment fonctionne AppCache

    AppCache modifie le processus habituel de chargement de fichier; si un cache existe déjà, les ressources sont directement chargées depuis ce cache, sans accéder au réseau, accélérant le chargement de la page. L'application web vérifie ensuite si le manifest a été mis à jour sur le serveur et le cas échéant, une nouvelle version du cache est téléchargée. Tout ceci se fait en tâche de fond et n'affecte pas les performances de manière significative.

    Les caches peuvent aussi devenir obsolètes. Si le manifest est supprimé du serveur, le navigateur supprime tous les caches qui utilise ce manifest, puis envoie un évènement "obsoleted" à l'objet application cache. Enfin, le statut du cache est défini comme OBSOLETE.

    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.

    Les ressources dans AppCache

    Les ressources dans le cache sont spécifiées par une URI qui pointe sur un fichier manifest (un fichier avec l'extension *.appcache). Ce fichier est référencé par l'attribut manifest dans l'élément html. Un manifest est téléchargé et traité pendant le processus de mise à jour d'AppCache. Les entrées doit avoir le même schéma, hôte et port que le manifest. 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.

    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.

    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.

    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. 

    Le 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.
    Comment
    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.
    FALLBACK: Passe à la section de secours.

    NETWORK: Passe à la section des sections en ligne sur la liste blanche.

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

    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.

    Note: Les URI relavives pointent vers les URI du cache manifest, et non vers les URI du document qui référence le manifest.

    Un exemple de manifest en cache

    Ci-dessous, un exemple simple de cache manifest — example.appcache utilisé par le site imaginaire 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
    

    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.

    Voici un exemple plus complet de cache manifest pour notre site imaginaire www.example.com. Nous utilisons dans cet exemple les sections FALLBACK et NETWORK pour préciser que la page network.html doit toujour ê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.

    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
    

    Indiquer un cache manifest

    Vous devez, pour utiliser le cache d'application, utiliser l'attribut manifest dans l'élément html comme suit:

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

    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.

    Le processus de mise à jour

    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. 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.
    3. 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.
    4. 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).

    Testing for updates

    Testing to see if an application has an updated cache manifest available can be done programmatically through Javascript. Since the cache may have been updated before any script using events to test for updates, scripts should always test window.applicationCache.status.

    function onUpdateReady() {
      alert('found new version!');
    }
    window.applicationCache.addEventListener('updateready', onUpdateReady);
    if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
      onUpdateReady();
    }

     To manually start testing for a new manifest you can use window.applicationCache.update().

    Gotchas

    • Since applications are using a cache, simply updating the files served under web pages is not enough to update files that have been cached. Updating the manifest will be required before the files are using their new source. This can be done programmatically through window.applicationCache.swapCache(), but already loaded resources will not be affected. In order to ensure resources are loaded from new version of the application cache refreshing the page is ideal.
    • it is a good idea to set expires headers on your web server for *.appcache files to expire immediately to avoid the risk of caching the manifest files. For example, in Apache you can configure this as follows:
      ExpiresByType text/cache-manifest "access plus 0 seconds"

    Storage location and clearing the offline cache

    In Chrome you can clear the offline cache by selecting "Clear browsing data..." in the preferences or by visiting chrome://appcache-internals/. Safari has a similar "Empty cache" setting in its preferences but a browser restart may also be required.

    In Firefox, the offline cache data is stored separately from the Firefox profile—next to the regular disk cache:

    • 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

    In Firefox the current status of the offline cache can be inspected on the about:cache page (under the "Offline cache device" heading).

    The offline cache is not cleared via Tools -> Clear Recent History (bug 538595)
    The offline cache is not cleared via Tools -> Options -> Advanced -> Network -> Offline data -> Clear Now (bug 538588).
    The offline cache can be cleared for each site separately using the "Remove..." button in Tools -> Options -> Advanced -> Network -> Offline data.

    See also clearing the DOM Storage data.

    Browser Compatibility

    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 ? Pas de support 11.0 3.2

     

    See also

    Étiquettes et contributeurs liés au document

    Contributeurs ayant participé à cette page : BenoitL, Mgjbot, whoshallsucceed, Nathymig
    Dernière mise à jour par : whoshallsucceed,