Ressources hors ligne dans Firefox

  • Raccourci de la révision : Ressources_hors_ligne_dans_Firefox
  • Titre de la révision : Ressources hors ligne dans Firefox
  • ID de la révision : 64161
  • Créé :
  • Créateur : BenoitL
  • Version actuelle ? Non
  • Commentaire +cat

Contenu de la révision

{{template.Fx_minversion_header(3)}} {{wiki.template('Traduction_à_relire')}} Firefox 3 implémente en grande partie la gestion de la mise en cache de ressources pour les applications web de HTML 5. Celle-ci s'effectue au travers du cache d'application — un ensemble de ressources provenant d'un manifeste fourni par l'application web.

Le cache d'application

{{template.Note("Firefox ne gère pour l\'instant pas de contrôle de versions dans les caches d\'applications.")}}

Étant donné que plusieurs applications web peuvent partager des ressources (et peuvent même partager une URI de manifeste), chaque application web maintient son propre cache. Cependant, les caches d'application sont groupés par leur URI de manifeste partagé, et ont un état de mise à jour commun. L'état de mise à jour est l'un des suivants :

idle
Le cache d'application n'est pas en train de télécharger des mises à jour.
checking
Le cache est en train de vérifier le manifeste de ressources pour s'assurer qu'il est à jour.
downloading
Le cache est en train d'être mis à jour avec du nouveau contenu sur base d'un manifeste de ressources modifié.

{{template.Fx_minversion_note(3, "Actuellement, seules les entrées de ressources sont gérées. Firefox ne gère pas encore la mise en cache opportuniste ou les entrées de récupération ; il est cependant recommandé que vous fournissez toujours une liste blanche de travail hors ligne le cas échéant, pour rester compatible dans l\'avenir.")}}

Ressources

Le cache contient toujours au moins une ressource, identifiée par son URI, d'au moins une des catégories suivantes :

Entrées implicites
Ce sont des ressources ajoutées au cache parce qu'un contexte de navigation principal visité par l'utilisateur comprenait un document indiquant que la ressource était dans son cache à l'aide de son attribut manifest.
Le manifeste
Il s'agit du manifeste de ressource lui-même, chargé depuis l'URI spécifiée dans l'attribut manifest de l'élément html d'une entrée implicite. Le manifeste est téléchargé et traité durant le processus de mise à jour du cache d'application. Les entrées implicites doivent avoir le même protocole, hôte et port que le manifeste.
Entrées explicites
Ce sont les ressources listées dans le manifeste du cache.
Entrées de récupération
Ce sont les ressources listées dans le manifeste du cache comme entrées de récupération. Ne sont pas encore gérées dans Firefox.
Entrées du cache opportuniste
Ce sont les ressources dont les URI correspondaient à un espace de noms de mise en cache opportuniste au moment de leur obtention, et ont donc été mises automatiquement dans le cache de l'application. Ne sont pas encore gérées dans Firefox.
Entrées dynamiques
Ce sont les ressources ajoutées programmatiquement à l'aide de la méthode add().

La liste blanche en ligne

La liste blanche en ligne peut contenir une série d'URI de ressources auxquelles l'application web aura besoin d'accéder depuis le serveur plutôt que depuis le cache hors ligne. Ceci permet au modèle de sécurité du navigateur de protéger l'utilisateur de failles de sécurité potentielles en limitant l'accès uniquement à des ressources approuvées.

{{template.Note("La liste blanche en ligne n\'est pas utilisée dans Firefox 3 ; cependant vous devriez en fournir une si vous en avez besoin, à la fois pour rester compatible avec les futures versions de Firefox et pour fonctionner dans d\'autres navigateurs implémentant la gestion des ressources hors ligne.")}}

Le manifeste de cache

Les fichiers de manifestes de cache doivent être fournis avec le type MIME text/cache-manifest, et toutes les ressources servies avec ce type MIME doivent suivre la syntaxe d'un manifeste de cache d'application tel que défini plus bas. Les manifestes de cache sont des fichiers texte au format UTF-8 et peuvent éventuellement contenir un caractère BOM. Les retours à la ligne peuvent être représentés par les caractères carriage return (U+000D), line feed (U+000A), ou les deux à la suite.

La première ligne du manifeste de cache doit être constituée de la chaîne "CACHE MANIFEST" (avec un seul caractère espace U+0020 entre les deux mots), éventuellement suivie d'espaces ou de tabulations. Tout autre texte sur cette ligne sera ignoré.

Le reste du manifeste de cache doit être constitué des types de lignes suivants (0 ou plus) :

Ligne vide
Vous pouvez utiliser des lignes vides, éventuellement constituées d'espaces ou de tabulations.
Commentaire
Les commentaires sont formés d'espaces ou tabulations (0 ou plus), suivies d'un seul caractère "#", éventuellement suivi d'autres caractères formant le texte du commentaire. Les commentaires peuvent uniquement être utilisés sur leurs propres lignes, et ne peuvent pas être ajoutés à d'autres lignes.
En-tête de section
Les en-têtes de section indiquent la section du manifeste de cache en train d'être manipulée. Trois en-têtes de section sont possibles :
En-tête de section Description
CACHE: Passe dans la section explicite. Il s'agit de la section par défaut.
FALLBACK: Passe dans la section de récupération (fallback).

{{template.Note("Cette section n\'est pas encore gérée dans Firefox, et sera ignorée.")}}

NETWORK: Passe dans la section de liste blanche en ligne.

{{template.Note("Cette section n\'est pas encore gérée dans Firefox, et sera ignorée ; il est cependant vivement recommandé de fournir une liste blanche appropriée.")}}

La ligne d'en-tête de section peut contenir des espaces vides, mais les deux points en fin de nom de section sont obligatoires.
Données pour la section courante
Le format des lignes de données varie d'une section à l'autre. Dans la section explicite, chaque ligne doit être une référence URI ou IRI valide à une ressource en cache. Des blancs sont permis avant et après l'URI ou IRI sur chaque ligne.

Les manifestes de cache peuvent passer et repasser d'une section à l'autre à l'envi (chaque en-tête de section peut donc être utilisé plus d'une fois), et les sections peuvent être vides.

{{template.Note("Les URI relatives le sont par rapport à l\'URI du manifeste de cache, pas à celle du document référençant le manifeste.")}}

Un exemple de manifeste de cache

Ceci est un manifeste de cache simple pour le site web imaginaire foo.com.

CACHE MANIFEST
# v1
# Ceci est un commentaire.
http://www.foo.com/index.html
http://www.foo.com/header.png
http://www.foo.com/blah/blah

Dans cet exemple, il n'y a pas d'en-tête de section, toutes les lignes sont donc supposées faire partie de la section explicite.

Le commentaire « v1 » s'y trouve pour une bonne raison. Comme le cache n'est mis à jour que lorsque le manifeste change, si les ressources sont modifiées (par exemple en mettant à jour l'image header.png avec du nouveau contenu), le manifeste doit être modifié afin de prévenir le navigateur qu'il doit rafraichir le cache. Cela peut se faire par n'importe quelle modification du manifeste, mais l'utilisation d'un numéro de version est une excellente manière de le faire.

Pour demander à Firefox d'utiliser le cache d'application hors ligne pour un site web donné, celui-ci doit utiliser l'attribut manifest sur l'élément html, comme ceci :

<html manifest="http://www.foo.com/cache-manifest">
  …
</html>

Le processus de mise à jour

  1. Lorsque Firefox visite un document renseignant l'attribut manifest, il envoie un évènement checking à l'objet window.applicationCache, et charge ensuite le fichier de manifeste en suivant les règles de mise en cache HTTP appropriées. Si la copie du manifeste actuellement en cache est à jour, l'évènement noupdate est envoyé à applicationCache, et le processus de mise à jour est terminé.
  2. Si le fichier de manifeste n'a pas changé depuis la dernière vérification de mise à jour, l'évènement noupdate est envoyé à applicationCache, et le processus de mise à jour est terminé. C'est pourquoi le fichier de manifeste doit être modifié si les ressources ont changé afin que Firefox sache qu'il doit remettre les ressources en cache.
  3. Si le fichier de manifeste a changé, tous les fichiers renseignés dans celui-ci — ainsi que ceux qui ont été ajouté dans le cache par des appels à applicationCache.add() — sont chargés dans un cache temporaire, selon les règles de mise en cache HTTP appropriées. Pour chaque fichier chargé dans le cache, un évènement progress est envoyé à l'objet applicationCache. Si une erreur se produit, un évènement error est envoyé, et la mise à jour s'interrompt.
  4. Une fois que tous les fichiers ont été effectivement récupérés, ils sont déplacés dans le véritable cache hors ligne en une opération atomique, et un évènement cached est envoyé à l'objet applicationCache.

Fonctionnalités non encore implémentées dans Firefox

Comme le brouillon de standard pour HTML 5 était encore en discussion à l'approche de la date de gel des fonctionnalités pour Firefox 3, certaines parties des possibilités de mise en cache hors ligne ne sont pas encore implémentées :

  1. Le brouillon de spécification du WHATWG indique que toutes les requêtes doivent venir du cache hors ligne, si disponible, même lorsque le navigateur est en ligne. Firefox n'accède actuellement au cache hors ligne que si le navigateur est hors ligne. C'est pour cette raison que la liste blanche en ligne n'est pas encore gérée.
  2. Firefox ne maintient actuellement pas de caches séparés pour chaque application web. Celles-ci devraient éviter de partager des ressources entre différents manifestes à moins de ne pas se soucier de conflits de versions entre les ressources. En général, cependant, les applications devraient conserver des copies séparées de chaque ressource.
  3. Firefox ne gère pas encore la mise en cache opportuniste ou les entrées de récupération (fallback).

Voir également

{{ wiki.languages( { "en": "en/Offline_resources_in_Firefox", "ja": "ja/Offline_resources_in_Firefox", "es": "es/Recursos_en_modo_desconectado_en_Firefox" } ) }}

Source de la révision

<p>{{template.Fx_minversion_header(3)}}
{{wiki.template('Traduction_à_relire')}}
Firefox 3 implémente en grande partie la gestion de la mise en cache de ressources pour les applications web de HTML 5. Celle-ci s'effectue au travers du <i>cache d'application</i> — un ensemble de ressources provenant d'un manifeste fourni par l'application web.
</p>
<h3 name="Le_cache_d.27application"> Le cache d'application </h3>
<p>{{template.Note("Firefox ne gère pour l\'instant pas de contrôle de versions dans les caches d\'applications.")}}
</p><p>Étant donné que plusieurs applications web peuvent partager des ressources (et peuvent même partager une URI de manifeste), chaque application web maintient son propre cache. Cependant, les caches d'application sont groupés par leur URI de manifeste partagé, et ont un <b>état de mise à jour</b> commun. L'état de mise à jour est l'un des suivants :
</p>
<dl><dt> <code>idle</code>
</dt><dd> Le cache d'application n'est pas en train de télécharger des mises à jour.
</dd><dt> <code>checking</code>
</dt><dd> Le cache est en train de vérifier le manifeste de ressources pour s'assurer qu'il est à jour.
</dd><dt> <code>downloading</code>
</dt><dd> Le cache est en train d'être mis à jour avec du nouveau contenu sur base d'un manifeste de ressources modifié.
</dd></dl>
<p>{{template.Fx_minversion_note(3, "Actuellement, seules les entrées de ressources sont gérées. Firefox ne gère pas encore la mise en cache opportuniste ou les entrées de récupération ; il est cependant recommandé que vous fournissez toujours une liste blanche de travail hors ligne le cas échéant, pour rester compatible dans l\'avenir.")}}
</p>
<h4 name="Ressources"> Ressources </h4>
<p>Le cache contient toujours au moins une ressource, identifiée par son URI, d'au moins une des catégories suivantes :
</p>
<dl><dt> Entrées implicites
</dt><dd> Ce sont des ressources ajoutées au cache parce qu'un contexte de navigation principal visité par l'utilisateur comprenait un document indiquant que la ressource était dans son cache à l'aide de son attribut <code>manifest</code>.
</dd><dt> Le manifeste
</dt><dd> Il s'agit du manifeste de ressource lui-même, chargé depuis l'URI spécifiée dans l'attribut <code>manifest</code> de l'élément <code>html</code> d'une entrée implicite. Le manifeste est téléchargé et traité durant le processus de mise à jour du cache d'application. Les entrées implicites doivent avoir le même protocole, hôte et port que le manifeste.
</dd><dt> Entrées explicites
</dt><dd> Ce sont les ressources listées dans le manifeste du cache.
</dd><dt> Entrées de récupération
</dt><dd> Ce sont les ressources listées dans le manifeste du cache comme entrées de récupération. <b>Ne sont pas encore gérées dans Firefox.</b>
</dd><dt> Entrées du cache opportuniste
</dt><dd> Ce sont les ressources dont les URI correspondaient à un espace de noms de mise en cache opportuniste au moment de leur obtention, et ont donc été mises automatiquement dans le cache de l'application. <b>Ne sont pas encore gérées dans Firefox.</b>
</dd><dt> Entrées dynamiques
</dt><dd> Ce sont les ressources ajoutées programmatiquement à l'aide de la méthode <code><a href="fr/NsIDOMOfflineResourceList#add.28.29">add()</a></code>.
</dd></dl>
<h4 name="La_liste__blanche_en_ligne"> La liste  blanche en ligne </h4>
<p>La liste blanche en ligne peut contenir une série d'URI de ressources auxquelles l'application web aura besoin d'accéder depuis le serveur plutôt que depuis le cache hors ligne. Ceci permet au modèle de sécurité du navigateur de protéger l'utilisateur de failles de sécurité potentielles en limitant l'accès uniquement à des ressources approuvées.
</p><p>{{template.Note("La liste blanche en ligne n\'est pas utilisée dans Firefox 3 ; cependant vous devriez en fournir une si vous en avez besoin, à la fois pour rester compatible avec les futures versions de Firefox et pour fonctionner dans d\'autres navigateurs implémentant la gestion des ressources hors ligne.")}}
</p>
<h3 name="Le_manifeste_de_cache"> Le manifeste de cache </h3>
<p>Les fichiers de manifestes de cache doivent être fournis avec le type MIME <code>text/cache-manifest</code>, et toutes les ressources servies avec ce type MIME doivent suivre la syntaxe d'un manifeste de cache d'application tel que défini plus bas. Les manifestes de cache sont des fichiers texte au format UTF-8 et peuvent éventuellement contenir un caractère BOM. Les retours à la ligne peuvent être représentés par les caractères <i>carriage return</i> (U+000D), <i>line feed</i> (U+000A), ou les deux à la suite.
</p><p>La première ligne du manifeste de cache doit être constituée de la chaîne "CACHE MANIFEST" (avec un seul caractère espace U+0020 entre les deux mots), éventuellement suivie d'espaces ou de tabulations. Tout autre texte sur cette ligne sera ignoré.
</p><p>Le reste du manifeste de cache doit être constitué des types de lignes suivants (0 ou plus) :
</p>
<dl><dt> Ligne vide
</dt><dd> Vous pouvez utiliser des lignes vides, éventuellement constituées d'espaces ou de tabulations.
</dd><dt> Commentaire
</dt><dd> Les commentaires sont formés d'espaces ou tabulations (0 ou plus), suivies d'un seul caractère "#", éventuellement suivi d'autres caractères formant le texte du commentaire. Les commentaires peuvent uniquement être utilisés sur leurs propres lignes, et ne peuvent pas être ajoutés à d'autres lignes.
</dd><dt> En-tête de section
</dt><dd> Les en-têtes de section indiquent la section du manifeste de cache en train d'être manipulée. Trois en-têtes de section sont possibles :
</dd></dl>
<blockquote>
<table class="standard-table">

<tbody><tr>
<th>En-tête de section
</th><th>Description
</th></tr>
<tr>
<td><code>CACHE:</code>
</td><td>Passe dans la section explicite. Il s'agit de la section par défaut.
</td></tr>
<tr>
<td><code>FALLBACK:</code>
</td><td>Passe dans la section de récupération (fallback).
<p>{{template.Note("Cette section n\'est pas encore gérée dans Firefox, et sera ignorée.")}}
</p>
</td></tr>
<tr>
<td><code>NETWORK:</code>
</td><td>Passe dans la section de liste blanche en ligne.
<p>{{template.Note("Cette section n\'est pas encore gérée dans Firefox, et sera ignorée ; il est cependant vivement recommandé de fournir une liste blanche appropriée.")}}
</p>
</td></tr></tbody></table>
</blockquote>
<dl><dd> La ligne d'en-tête de section peut contenir des espaces vides, mais les deux points en fin de nom de section sont obligatoires.
</dd><dt> Données pour la section courante
</dt><dd> Le format des lignes de données varie d'une section à l'autre. Dans la section explicite, chaque ligne doit être une référence URI ou IRI valide à une ressource en cache. Des blancs sont permis avant et après l'URI ou IRI sur chaque ligne.
</dd></dl>
<p>Les manifestes de cache peuvent passer et repasser d'une section à l'autre à l'envi (chaque en-tête de section peut donc être utilisé plus d'une fois), et les sections peuvent être vides.
</p><p>{{template.Note("Les URI relatives le sont par rapport à l\'URI du manifeste de cache, pas à celle du document référençant le manifeste.")}}
</p>
<h4 name="Un_exemple_de_manifeste_de_cache"> Un exemple de manifeste de cache </h4>
<p>Ceci est un manifeste de cache simple pour le site web imaginaire <span class="plain">foo.com</span>.
</p>
<pre class="eval">CACHE MANIFEST
# v1
# Ceci est un commentaire.
<span class="plain">http://www.foo.com/index.html</span>
<span class="plain">http://www.foo.com/header.png</span>
<span class="plain">http://www.foo.com/blah/blah</span>
</pre>
<p>Dans cet exemple, il n'y a pas d'en-tête de section, toutes les lignes sont donc supposées faire partie de la section explicite.
</p><p>Le commentaire « v1 » s'y trouve pour une bonne raison. Comme le cache n'est mis à jour que lorsque le manifeste change, si les ressources sont modifiées (par exemple en mettant à jour l'image <code>header.png</code> avec du nouveau contenu), le manifeste doit être modifié afin de prévenir le navigateur qu'il doit rafraichir le cache. Cela peut se faire par n'importe quelle modification du manifeste, mais l'utilisation d'un numéro de version est une excellente manière de le faire.
</p><p>Pour demander à Firefox d'utiliser le cache d'application hors ligne pour un site web donné, celui-ci doit utiliser l'attribut <code>manifest</code> sur l'élément <code>html</code>, comme ceci :
</p>
<pre class="eval"><span class="plain">&lt;html manifest="http://www.foo.com/cache-manifest"&gt;</span>
  …
&lt;/html&gt;
</pre>
<h3 name="Le_processus_de_mise_.C3.A0_jour"> Le processus de mise à jour </h3>
<ol><li> Lorsque Firefox visite un document renseignant l'attribut <code>manifest</code>, il envoie un évènement <code>checking</code> à l'objet <code><a href="fr/DOM/window.applicationCache">window.applicationCache</a></code>, et charge ensuite le fichier de manifeste en suivant les règles de mise en cache HTTP appropriées. Si la copie du manifeste actuellement en cache est à jour, l'évènement <code>noupdate</code> est envoyé à <code>applicationCache</code>, et le processus de mise à jour est terminé.
</li><li> Si le fichier de manifeste n'a pas changé depuis la dernière vérification de mise à jour, l'évènement <code>noupdate</code> est envoyé à <code>applicationCache</code>, et le processus de mise à jour est terminé. C'est pourquoi le fichier de manifeste doit être modifié si les ressources ont changé afin que Firefox sache qu'il doit remettre les ressources en cache.
</li><li> Si le fichier de manifeste a changé, tous les fichiers renseignés dans celui-ci — ainsi que ceux qui ont été ajouté dans le cache par des appels à <code><a href="fr/NsIDOMOfflineResourceList#add.28.29">applicationCache.add()</a></code> — sont chargés dans un cache temporaire, selon les règles de mise en cache HTTP appropriées. Pour chaque fichier chargé dans le cache, un évènement <code>progress</code> est envoyé à l'objet <code>applicationCache</code>. Si une erreur se produit, un évènement <code>error</code> est envoyé, et la mise à jour s'interrompt.
</li><li> Une fois que tous les fichiers ont été effectivement récupérés, ils sont déplacés dans le véritable cache hors ligne en une opération atomique, et un évènement <code>cached</code> est envoyé à l'objet <code>applicationCache</code>.
</li></ol>
<h3 name="Fonctionnalit.C3.A9s_non_encore_impl.C3.A9ment.C3.A9es_dans_Firefox"> Fonctionnalités non encore implémentées dans Firefox </h3>
<p>Comme le brouillon de standard pour HTML 5 était encore en discussion à l'approche de la date de gel des fonctionnalités pour Firefox 3, certaines parties des possibilités de mise en cache hors ligne ne sont pas encore implémentées :
</p>
<ol><li> Le brouillon de spécification du WHATWG indique que toutes les requêtes doivent venir du cache hors ligne, si disponible, même lorsque le navigateur est en ligne. Firefox n'accède actuellement au cache hors ligne que si le navigateur est hors ligne. C'est pour cette raison que la liste blanche en ligne n'est pas encore gérée.
</li><li> Firefox ne maintient actuellement pas de caches séparés pour chaque application web. Celles-ci devraient éviter de partager des ressources entre différents manifestes à moins de ne pas se soucier de conflits de versions entre les ressources. En général, cependant, les applications devraient conserver des copies séparées de chaque ressource.
</li><li> Firefox ne gère pas encore la mise en cache opportuniste ou les entrées de récupération (fallback).
</li></ol>
<h3 name="Voir_.C3.A9galement"> Voir également </h3>
<ul><li> <a class="external" href="http://www.w3.org/TR/2008/WD-html5-20080122/#appcache">Brouillon de travail HTML 5 : Application caches</a>
</li><li> {{template.Interface("nsIDOMOfflineResourceList")}}
</li></ul>
{{ wiki.languages( { "en": "en/Offline_resources_in_Firefox", "ja": "ja/Offline_resources_in_Firefox", "es": "es/Recursos_en_modo_desconectado_en_Firefox" } ) }}
Revenir à cette révision