Usando caché de aplicaciones

  • Enlace amigable (slug) de la revisión: Recursos_offline_en_firefox
  • Título de la revisión: Usando caché de aplicaciones
  • Id de la revisión: 348061
  • Creada:
  • Creador: MPoli
  • ¿Es la revisión actual? No
  • Comentario

Contenido de la revisión

Introducción

HTML5 proporciona un mecanismo de caché de aplicación que permite que las aplicaciones basadas en la web se ejecuten sin conexión. Los desarrolladores pueden usar la interface de Caché de apliaciones (AppCache) para especificar los recursos que el navegador debería guardar en caché y tener disponibles para los usuarios cuando no estén conectados. Las aplicaciones que están en caché se cargan y funcionan correctamente aunque los usuarios hagan clic en el botón recargar cuando no están conectados.

Usar el caché de aplicaciones le da a la aplicación los siguientes beneficios:

  • Navegación sin conexión: los usuarios pueden navegar un sitio aún cuando no estén conectados.
  • Velocidad: los recursos en caché son locales, y por lo tanto, se cargan más rápido.
  • Carga al servidor reducida: el navegador solamente descarga desde el servidor recursos que han cambiado..

¿Cómo funciona el caché de aplicaciones?

Habilitando caché de apliaciones

Para habilitar el caché de apliaciones, debe incluir el atributo {{htmlattrxref("manifest", "html")}} en el elemento {{HTMLElement("html")}} en las páginas de sus aplicaciones, como se muestra en el siguiente ejemplo:

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

El atributo manifest referencua un archivo manifiesto de cache, que es un archivo de texto que lista los recursos (archivos) que el navegador deberá guardar en caché para la aplicación.

Debería incluir el atributo manifest en cada página de la aplicación que quiera guardar en caché. El navegador no guardará páginas que no contengan el atributo  manifest, a menos que esas páginas estén específicamente listadas en el archivo de manifiesto en sí mismo. No es necesario listar todas las páginas que se quieran guardar en caché en el archivo de manfifesto, el navegador implícitamente agrega cada página que el usuario visite y tenga el atributo manifest establecido para caché de aplicación.

Algunos navegadores (ej. Firefox) muestran una notificación la primera vez que un usuario carga una aplicación que usa caché de aplicaciones La barra de notificaciones muestra un mensaje parecido a :

Este sitio web (www.ejemplo.com) está pidiendo guardar datos en su equpo para suar sin conexión. [Permitir] [Nunca para este sitio] [No por ahora]

El término "offline(-enabled) applications" a veces se refiere específicamente a aplicaciones a las que el usuario ha permitido que usen capacidades sin conexión.

Cargando documentos

Es uso de caché de aplicaciones modifica el proceso normal de la carga de un documento:

  • Si existe caché de aplicaciones, el navegador carga el documento y sus recursos asociados directamente desde ahí, sin acceder a la red. Esto acelera el tiempo de carga del documento.
  • El navegador entonces verifica si hubo actualizaciones al manifiesto de caché en el servidor.
  • Si el manifiesto de caché fue actualizado, el navegador descarga la nueva versión del archivo y de los recursos listados en él. Esto se realiza en segundo plano y no afecta el rendimiento de forma significativa.

El proceso para cargar documentos y actualizar el caché de aplicaciones está especificado con gran detalle aquí debajo:

  1. Cuando el navegador visita un documento que incluye el atributo manifest, si no existe caché de apliaciones, el navegador carga el documento y baja todas las entradas listadas en el archivo de manifiesto, creando la primera versón de caché de aplicaciones. 
  2. Posteriores visitas a ese documento causan que el navegador cargue el documento y otros archivos especificados en el manifiesto desde el caché de aplicaciones (no desde el servidor).  Además, el navegador envía un evento checking al objeto window.applicationCache y descarga el archivo de manifiesto, siguiendo las reglas de caché HTTP apropiadas.
  3. Si la copia del manifiesto actualmente en caché está actualizada, el navegador envía un evento noupdate al objeto applicationCache y el proceso de actualización está completo. Hay que tener en cuenta que si se cambia en el servidor cualquier recurso en caché, se deberá cambiar también el archivo de manifiesto, para que el navegador sepa que deberá descargar los recursos nuevamente.
  4. Si el archivo de manifiesto ha cambiado, todos los archivos listados en el manifiesto—así como los que se agregaron al caché llamando applicationCache.add()—se descargarán en un caché temporario, siguiendo las reglas de caché  HTTP apropiadas. Para cada archivo descargado en este caché temporario, el navegador envía un evento progress al objeto applicationCache. Si ocurre cualquier error, el navegador envía un evento error y la actualización se detiene.
  5. Una vez que todos los archivos han sido recuperados exitosamente, son movidos al caché sin conexión real automáticamente y un evento cached es enviado al objeto applicationCache. Como el documento ya ha sido cargado en el navegador desde caché, la actualización no se mostrará hasta que el documento sea recargado (ya sea manualmente o por programa).

Ubicación del almacenamiento y limpiando el caché sin conexión

En Chrome se puede limpiar el caché sin conexión seleccionando "Clear browsing data..." en las preferencias o visitando chrome://appcache-internals/. Safari tiene una configuración similar"Vaciar cache" en sus preferencias, pero se requiere el reinicio del navegador.

En Firefox, el caché sin conexión se guarda en un lugar separado del perfil de Firefox profile—cerca del caché de disco regular:

  • Windows Vista/7: C:\Users\<usuario>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<nombre de perfil>\OfflineCache
  • Mac/Linux: /Users/<usuario>/Library/Caches/Firefox/Profiles/<salt>.<nombre de perfil>/OfflineCache

En Firefox el estado actual del caché de aplicaciones puede ser inspeccionado en la página the about:cache (debajo del encabezado "Offline cache device"). El caché sin conexión pude limpiarse para cada sitio por seaparado usando el botón "Eliminar..." Herramientas -> Opciones -> Avanzadas -> Red -> Datos sin conexión.

Antes de Firefox 11, ni Herramientas -> Limpiar historial reciente ni Herramientas -> Opciones -> Avanzadas -> Red -> Datos sin conexión -> Limpiar ahora borraban el caché sin conexión. Esto ha sido solucionado.

Véase también limpiar los datos de almacenamiento de DOM.

Los cachés de aplicaciones también pueden quedar obsoletos. Si el archivo de manifiesto de una aplicación es eliminado del servidor, el navegadore elimina todo caché de la aplicación que use aquel manifiesto y envía un evento "obsoleted" al objeto applicationCache. Esto cambia el estdo de caché de la aplicación a OBSOLETE.

El archivo de manifiesto de caché

Referenciando un archivo de manifiesto de caché

El atributo manifest en una aplicación web puede especificar ya sea la ruta relativa de un archivo de manifiesto de caché o una URL absoluta (URLs absolutas deben estar en el mismo origen que la aplicación). Un archivo de manifiesto de caché puede tener cualquier extensión de archivo, pero debe ser enviada con el tipo MIME text/cache-manifest.

Nota: En servidores Apache, el tipo MIME para los archivos de manifiesto (.appcache) puede establecerse agregando AddType text/cache-manifest .appcache a un archivo .htaccess dentro del directorio raíz o del mismo directorio que la aplicación.

Entradas en el archivo de manifiesto de caché

El archivo de manifiesto de caché es un archivo de texto simple que lista los recursos que el navegador debería guardar en caché para acceder sin conexión. Los recursos son identificados por URI. Las entradas listadas en el manifiesto de caché deben tener el mismo esquema, servidor y puerto que el manifiesto. 

Ejemplo 1: un archivo de manifiesto de caché simple

El siguiente es un archivo de manifiesto de caché simple, ejemplo.appcache, para un sitio web imaginario en www.ejemplo.com.

CACHE MANIFEST
# v1 - 2011-08-13
# Esto es un comentario.
http://www.ejemplo.com/index.html
http://www.ejemplo.com/encabezado.png
http://www.ejemplo.com/blah/blah

Un archivo de manifiesto de caché puede incluir tres secciones (CACHENETWORK y FALLBACK, discutidas debajo). En el ejemplo mencionado, no hay encabezado de sección, así que todoas las líneas de datos se asumen como si estuvieran en la sección explícita (CACHE), lo que significa que el navegador deberá guardar en caché todos los recursos listados en el caché de aplicación. Los recursos pueden ser especificados como URLs absolutas o relativas (ej. index.html).

El comentario "v1" en el ejemplo está ahí por una buena razón. Los navegadores solamente actualizan el caché de aplicación cuando el archivo de manifiesto cambia byte por byte. Si se cambia un recurso en caché (por ejemplo, si se actualiza la imagen header.png con nuevo contenido), se debe cambiar el contenido del archivo de manifiesto para que los navegadores sepan que se necesita actualizar el caché. Se puede hacer cualquier cambio al archivo de manifiesto, pero cambiar el número de versión es una práctica recomendada.

Importante: No hay que especificar el manifiesto en el mismo archivo de manifiesto Do not specify the manifest, porque sería casi imposible informar al navegador que hay un nuevo manifiesto disponible.

Secciones en un archivo de manifiesto de caché: CACHENETWORK y FALLBACK

Un manifiesto puede tener tres secciones distintas: CACHENETWORK y FALLBACK.

CACHE:
Esta es la sección predeterminada para las entradas en el archivo de manifiesto de caché. Los archivos listados bajo el encabezado de sección CACHE: (o inmediatamente después de la línea CACHE MANIFEST) son guardados en caché explícitamente después de ser descargados la primera vez.
NETWORK:
Los archivos listados bajo el encabezado de sección NETWORK: en el archivo de manifiesto de caché son recursos en lista blanca que requieren una conexión al servidor. Todos los pedidos a esos recursos evitan el caché aunque el usuario esté desconectado. Se pueden usar comodines.
FALLBACK:
La sección FALLBACK: especifica las páginas que el navegador debería usar si un recurso no es accesible. Cada entrada en esta sección lista dos URIs—lla primera es el recurso, la seguda es el fallback. Ambas URIs deben ser relativas y del mismo origen que el archivo de manifiesto. Se pueden usar comodines.

Las secciones CACHENETWORK y FALLBACK pueden lsitarse en cualquier orden en el archivo de manifiesto y cada sección puede aparecer más de una vez en un manifiesto.

Ejemplo 2: un archivo de manifiesto de caché más completo

El siguiente es un archivo de manifiesto de caché para el sitio web imaginario en www.ejemplo.com:

CACHE MANIFEST
# v1 2011-08-14
# Este es otro comentario
index.html
cache.html
style.css
image1.png

# Usar desde la red si está disponible
NETWORK:
network.html

# Contenido de fallback
FALLBACK:
/ fallback.html

Este ejemplo usa las secciones NETWORK y FALLBACK para especificar la página network.html que deber ser recuperada desde la red y que la página fallback.html servirá como fallback (ej. en caso que una conexión al servidor no pueda establecerse).

Estructura de un archivo de manifiesto de caché

Los archivos de manifiesto de caché deben enviarse con el tipo MIME text/cache-manifest. Todos los recursos servidos usando este tipo MIME deben seguir la sintaxis para un manifiesto de caché de aplicación, como se define en esta sección.

Los manifiestos de caché son archivos de texto en formato UTF-8 y pueden incluír opcionalmente un caracter BOM. Las nuevas líneas pueden ser representadas por salto de línea (U+000A), retorno de carro (U+000D) o ambos retorno de carro y salto de línea.

La primera línea del manifiesto de caché debe consistir en la cadena CACHE MANIFEST (con un solo espacio U+0020 entre ambas palabras), seguido de cero o más espacios co caracteres de tabulación. Cualquier otro texto en la línea es ignorado.

El resto del manifiesto de caché debe estar compuesto por cero o más de las siguientes líneas:

Línea en blanco
Se pueden usar líneas en blanco compuestas por cero o más espacios y caracteres de tabulación.
Comentario
Los comentarios consisten en cero o más tabulaciones o espacios seguidos pur un caracter # seguido de cero o más caracteres del texto del comentario. Los comentarios pueden usarse solamente en sus propias líneas y no pueden agregarse a otras líneas. Esto significa que no puede espcificar identificadores de fragmento.
Encabezado de sección
Los encabezados de sección especifican qué sección del manifiesto de caché está siendo manipulada. Hay tres encabezados de sección posibles:
Encabezado de sección Descripción
CACHE: Cambia a la sección explícita del manifiesto de caché (esta es la sección predeterminada).
NETWORK: Cambia a la sección de lista blanca del manifiesto de caché.
FALLBACK: Cambia a la sección fallback del manifiesto de caché.
La líena de encabezado de sección puede incluir espacios en blanco, pero debe incluir los dos puntos (:) en el nombre de sección.
Datos de sección
El formato de las líneas de datos varía de sección a sección. En la sección explícita (CACHE:), cada línea es una URI o referencia IRI a un recurso a guardar en caché (no se permiten caracteres comodines en esta sección). El espacio en blanco se permite antes y después de la URI o IRI en cada línea. En la sección Fallback cada línea es una URI o referencia IRI válida a un recurso, seguida por un recurso de fallback que será enviado cuando la comunicación con el servidor no pueda establecerse. En la sección Network, cada línea es una URI o referencia IRI válida a un recurso a obtener desde la red (se permite el caracter comodín * en esta sección).
Nota: URIs relativas son relativas a la URI del manifiesto de caché, no a la URI del documento que hace referencia al manifiesto.

Los archivos de manifiesto de caché pueden cambiar de sección a sección a voluntad (cada encabezado de sección puede usarse más de una vez) y se permite que las secciones estén vacías.

Recursos en un caché de aplicación

Un caché de aplicación siempre incluye al menos un recurso, identificado por URI. Todos los recursos entran en una de las siguientes categorías:

Entradas maestras
Estos son recursos adicionados al caché porque un contexto de navegación visitado por el usuario incluyó un documento que indicó que estaba en caché usando el atributo manifest.
Entradas explícitas
Estos recursos están listados explícitamente en el archivo de manifiesto de caché de la aplicación.
Entradas de red
Estos son recursos listados en el archivo de manifiesto de caché de la aplicación como entradas de red.
Entradas de fallback
Estos son recursos listados en el archivo de manifiesto de caché de la aplicación como entradas de fallback.
Nota: Los recursos pueden estar etiquetados en múltiples categorías y por lo tanto ser categorizados como entradas múltiples.  Por ejemplo, una entrada puede ser explícita y fallback a la vez.

Las categorías de recursos se describen con más detalle debajo.

Entradas maestras

Una entrada maestra es cualquier archivo HTML que incluya un atributo {{ htmlattrxref("manifest","html") }} en su elemento {{ HTMLElement("html") }}.  Por ejemplo, digamos que tenemos el archivo http://www.ejemplo.com/entrada.html, que incluye el siguiente texto:

<html manifest="ejemplo.appcache">
  <h1>Ejemplo de cache de aplicacion</h1>
</html>

Si entrada.html no esta listado en el archivo de manifiesto de cache ejemplo.appcache, visitar la pagina entrada.html causa que se agregue al cache de aplicacion el archivo entrada.html como entrada maestra.

Entradas explicitas

Las entradas explicitas son recursos que estan listados explicitamente en la seccion CACHE de un archivo de manifiesto de cache.

Entradas de red

La seccion NETWORK de un archivo de manifiesto de cache especifica recurso para los cuales una aplicacion web requiere acceso a internet. Las entradas de red en el cache de aplicacion son escencialmente una "lista blanca online"—URIs especificadas en la seccion NETWORK se cargaran desde el servidor en lugar del cache. Esto permite que el modelo de seguridad del navegador proteja al usuario de problemas de seguridad potenciales al limitar el acceso a recursos aprobados.

Como ejemplo, puede usar entradas en la seccion red para cargar y ejecutar scripts y otro codigo desde el servidor en lugar del cache:

CACHE MANIFEST
NETWORK:
/api

The cache manifest section listed above ensures that requests to load resources contained in the http://www.example.com/api/ subtree always go to the network without attempting to access the cache.

Note: Simply omitting master entries (files that have the manifest attribute set in the html element) from the manifest file would not have the same result, because master entries will be added—and subsequently served from—the application cache. 

Fallback entries

Fallback entries are used when an attempt to load a resource fails.  For example, let's say the cache manifest file http://www.example.com/example.appcache includes the following content:

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

Any request to http://www.example.com/example/bar/ or any of its subdirectories and their content cause the browser to issue a network request to attempt to load the requested resource.  If the attempt fails, due to either a network failure or a server error of some kind, the browser loads the file example.html instead.

Cache states

Each application cache has a state, which indicates the current condition of the cache.  Caches that share the same manifest URI share the same cache state, which can be one of the following:

UNCACHED
A special value that indicates that an application cache object is not fully initialized.
IDLE
The application cache is not currently in the process of being updated.
CHECKING
The manifest is being fetched and checked for updates.
DOWNLOADING
Resources are being downloaded to be added to the cache, due to a changed resource manifest.
UPDATEREADY
There is a new version of the application cache available.  There is a corresponding updateready event, which is fired instead of the cached event when a new update has been downloaded but not yet activated using the swapCache() method.
OBSOLETE
The application cache group is now obsolete.

Testing for updates to the cache manifest

You can programmatically test to see if an application has an updated cache manifest file, using JavaScript. Since a cache manifest file may have been updated before a script attaches event listeners 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 file, you can use 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"

Browser Compatibility

{{ 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

Note: Versions of Firefox prior to 3.5 ignore the NETWORK and FALLBACK sections of the cache manifest file.

See also

{{ HTML5ArticleTOC() }}

 

Fuente de la revisión

<h2 id="Introducci.C3.B3n">Introducción</h2>
<p><a href="https://developer.mozilla.org/en-US/docs/HTML/HTML5" title="/en-US/docs/HTML/HTML5">HTML5</a> proporciona un mecanismo de <em>caché de aplicación</em> que permite que las aplicaciones basadas en la web se ejecuten sin conexión. Los desarrolladores pueden usar la interface de <strong>Caché de apliaciones</strong> (<em>AppCache</em>) para especificar los recursos que el navegador debería guardar en caché y tener disponibles para los usuarios cuando no estén conectados. Las aplicaciones que están en caché se cargan y funcionan correctamente aunque los usuarios hagan clic en el botón recargar cuando no están conectados.</p>
<p>Usar el caché de aplicaciones le da a la aplicación los siguientes beneficios:</p>
<ul>
  <li>Navegación sin conexión: los usuarios pueden navegar un sitio aún cuando no estén conectados.</li>
  <li>Velocidad: los recursos en caché son locales, y por lo tanto, se cargan más rápido.</li>
  <li>Carga al servidor reducida: el navegador solamente descarga desde el servidor recursos que han cambiado..</li>
</ul>
<h3 id=".C2.BFC.C3.B3mo_funciona_el_cach.C3.A9_de_aplicaciones.3F">¿Cómo funciona el caché de aplicaciones?</h3>
<h3 id="Habilitando_cach.C3.A9_de_apliaciones">Habilitando caché de apliaciones</h3>
<p>Para habilitar el caché de apliaciones, debe incluir el atributo {{htmlattrxref("manifest", "html")}} en el elemento {{HTMLElement("html")}} en las páginas de sus aplicaciones, como se muestra en el siguiente ejemplo:</p>
<div>
  <pre class="brush: html">
<span class="brush: html">&lt;html manifest="ejemplo.appcache"&gt; </span>
  ...
&lt;/html&gt;
</pre>
</div>
<p>El atributo manifest referencua un archivo <strong>manifiesto de cache</strong>, que es un archivo de texto que lista los recursos (archivos) que el navegador deberá guardar en caché para la aplicación.</p>
<p>Debería incluir el atributo <code>manifest</code> en cada página de la aplicación que quiera guardar en caché. El navegador no guardará páginas que no contengan el atributo&nbsp; <code>manifest</code>, a menos que esas páginas estén específicamente listadas en el archivo de manifiesto en sí mismo. No es necesario listar todas las páginas que se quieran guardar en caché en el archivo de manfifesto, el navegador implícitamente agrega cada página que el usuario visite y tenga el atributo <code>manifest</code> establecido para caché de aplicación.</p>
<p>Algunos navegadores (ej. Firefox) muestran una notificación la primera vez que un usuario carga una aplicación que usa caché de aplicaciones La barra de notificaciones muestra un mensaje parecido a :</p>
<p style="margin-left: 40px; ">Este sitio web (<code>www.ejemplo.com</code>) está pidiendo guardar datos en su equpo para suar sin conexión. [Permitir] [Nunca para este sitio] [No por ahora]</p>
<p>El término "offline(-enabled) applications" a veces se refiere específicamente a aplicaciones a las que el usuario ha permitido que usen capacidades sin conexión.</p>
<h3 id="Cargando_documentos">Cargando documentos</h3>
<div>
  <p>Es uso de caché de aplicaciones modifica el proceso normal de la carga de un documento:</p>
  <ul>
    <li>Si existe caché de aplicaciones, el navegador carga el documento y sus recursos asociados directamente desde ahí, sin acceder a la red. Esto acelera el tiempo de carga del documento.</li>
    <li>El navegador entonces verifica si hubo actualizaciones al manifiesto de caché en el servidor.</li>
    <li>Si el manifiesto de caché fue actualizado, el navegador descarga la nueva versión del archivo y de los recursos listados en él. Esto se realiza en segundo plano y no afecta el rendimiento de forma significativa.</li>
  </ul>
  <p>El proceso para cargar documentos y actualizar el caché de aplicaciones está especificado con gran detalle aquí debajo:</p>
</div>
<ol>
  <li>Cuando el navegador visita un documento que incluye el atributo <code>manifest</code>, si no existe caché de apliaciones, el navegador carga el documento y baja todas las entradas listadas en el archivo de manifiesto, creando la primera versón de caché de aplicaciones.&nbsp;</li>
  <li>Posteriores visitas a ese documento causan que el navegador cargue el documento y otros archivos especificados en el manifiesto desde el caché de aplicaciones (no desde el servidor).&nbsp; Además, el navegador envía un evento <code>checking</code> al objeto <code><a href="https://developer.mozilla.org/en/DOM/window.applicationCache" title="en/DOM/window.applicationCache">window.applicationCache</a></code> y descarga el archivo de manifiesto, siguiendo las reglas de caché HTTP apropiadas.</li>
  <li>Si la copia del manifiesto actualmente en caché está actualizada, el navegador envía un evento <code>noupdate</code> al objeto <code>applicationCache</code> y el proceso de actualización está completo. Hay que tener en cuenta que si se cambia en el servidor cualquier recurso en caché, se deberá cambiar también el archivo de manifiesto, para que el navegador sepa que deberá descargar los recursos nuevamente.</li>
  <li>Si el archivo de manifiesto <em>ha</em> cambiado, todos los archivos listados en el manifiesto—así como los que se agregaron al caché llamando <code><a href="https://developer.mozilla.org/en/nsIDOMOfflineResourceList#add.28.29" title="en/nsIDOMOfflineResourceList#add.28.29">applicationCache.add()</a></code>—se descargarán en un caché temporario, siguiendo las reglas de caché&nbsp; HTTP apropiadas. Para cada archivo descargado en este caché temporario, el navegador envía un evento <code>progress</code> al objeto <code>applicationCache</code>. Si ocurre cualquier error, el navegador envía un evento <code>error</code> y la actualización se detiene.</li>
  <li>Una vez que todos los archivos han sido recuperados exitosamente, son movidos al caché sin conexión real automáticamente y un evento <code>cached</code> es enviado al objeto <code>applicationCache</code>. Como el documento ya ha sido cargado en el navegador desde caché, la actualización no se mostrará hasta que el documento sea recargado (ya sea manualmente o por programa).</li>
</ol>
<h2 id="Ubicaci.C3.B3n_del_almacenamiento_y_limpiando_el_cach.C3.A9_sin_conexi.C3.B3n">Ubicación del almacenamiento y limpiando el caché sin conexión</h2>
<p>En Chrome se puede limpiar el caché sin conexión seleccionando "Clear browsing data..." en las preferencias o visitando <a class="external" title="chrome://appcache-internals/">chrome://appcache-internals/</a>. Safari tiene una configuración similar"Vaciar cache" en sus preferencias, pero se requiere el reinicio del navegador.</p>
<p>En Firefox, el caché sin conexión se guarda en un lugar separado del perfil de Firefox profile—cerca del caché de disco regular:</p>
<ul>
  <li>Windows Vista/7: <code>C:\Users\&lt;usuario&gt;\AppData\<strong>Local</strong>\Mozilla\Firefox\Profiles\&lt;salt&gt;.&lt;nombre de perfil&gt;\OfflineCache</code></li>
  <li>Mac/Linux:&nbsp;<code>/Users/&lt;usuario&gt;/Library/Caches/Firefox/Profiles/&lt;salt&gt;.&lt;nombre de perfil&gt;/OfflineCache</code></li>
</ul>
<p>En Firefox el estado actual del caché de aplicaciones puede ser inspeccionado en la página the <code>about:cache</code> (debajo del encabezado "Offline cache device"). El caché sin conexión pude limpiarse para cada sitio por seaparado usando el botón "Eliminar..." Herramientas -&gt; Opciones -&gt; Avanzadas -&gt; Red -&gt; Datos sin conexión.</p>
<p>Antes de Firefox 11, ni Herramientas -&gt; Limpiar historial reciente ni Herramientas -&gt; Opciones -&gt; Avanzadas -&gt; Red -&gt; Datos sin conexión -&gt; Limpiar ahora borraban el caché sin conexión. Esto ha sido solucionado.</p>
<p>Véase también <a href="https://developer.mozilla.org/en/DOM/Storage#Storage_location_and_clearing_the_data" title="en/DOM/Storage#Storage location and clearing the data">limpiar los datos de almacenamiento de DOM</a>.</p>
<div>
  <p>Los cachés de aplicaciones también pueden quedar obsoletos. Si el archivo de manifiesto de una aplicación es eliminado del servidor, el navegadore elimina todo caché de la aplicación que use aquel manifiesto y envía un evento "obsoleted" al objeto <code>applicationCache</code>. Esto cambia el estdo de caché de la aplicación a <code>OBSOLETE</code>.</p>
</div>
<h2 id="El_archivo_de_manifiesto_de_cach.C3.A9">El archivo de manifiesto de caché</h2>
<h3 id="Referenciando_un_archivo_de_manifiesto_de_cach.C3.A9">Referenciando un archivo de manifiesto de caché</h3>
<p>El atributo <code>manifest</code> en una aplicación web puede especificar ya sea la ruta relativa de un archivo de manifiesto de caché o una URL absoluta (URLs absolutas deben estar en el mismo origen que la aplicación). Un archivo de manifiesto de caché puede tener cualquier extensión de archivo, pero debe ser enviada con el tipo MIME <code>text/cache-manifest</code>.</p>
<div class="note">
  <strong>Nota: </strong>En servidores Apache, el tipo MIME para los archivos de manifiesto (.appcache) puede establecerse agregando <code>AddType text/cache-manifest .appcache</code> a un archivo .htaccess dentro del directorio raíz o del mismo directorio que la aplicación.</div>
<h3 id="Entradas_en_el_archivo_de_manifiesto_de_cach.C3.A9">Entradas en el archivo de manifiesto de caché</h3>
<p>El archivo de manifiesto de caché es un archivo de texto simple que lista los recursos que el navegador debería guardar en caché para acceder sin conexión. Los recursos son identificados por URI. Las entradas listadas en el manifiesto de caché deben tener el mismo esquema, servidor y puerto que el manifiesto.&nbsp;</p>
<h3 id="Ejemplo_1.3A_un_archivo_de_manifiesto_de_cach.C3.A9_simple">Ejemplo 1: un archivo de manifiesto de caché simple</h3>
<div>
  <p>El siguiente es un archivo de manifiesto de caché simple,&nbsp;<code>ejemplo.appcache</code>, para un sitio web imaginario en <span class="nowiki">www.ejemplo.com</span>.</p>
  <pre class="eval">
CACHE MANIFEST
# v1 - 2011-08-13
# Esto es un comentario.
<span class="nowiki">http://www.ejemplo.com/index.html</span>
<span class="nowiki">http://www.ejemplo.com/encabezado.png</span>
<span class="nowiki">http://www.ejemplo.com/blah/blah</span>
</pre>
  <p>Un archivo de manifiesto de caché puede incluir tres secciones (<code>CACHE</code>,&nbsp;<code>NETWORK</code> y <code>FALLBACK</code>, discutidas debajo). En el ejemplo mencionado, no hay encabezado de sección, así que todoas las líneas de datos se asumen como si estuvieran en la sección explícita (<code>CACHE</code>), lo que significa que el navegador deberá guardar en caché todos los recursos listados en el caché de aplicación. Los recursos pueden ser especificados como URLs absolutas o relativas (ej. <code>index.html</code>).</p>
  <p>El comentario "v1" en el ejemplo está ahí por una buena razón. Los navegadores solamente actualizan el caché de aplicación cuando el archivo de manifiesto cambia byte por byte. Si se cambia un recurso en caché (por ejemplo, si se actualiza la imagen <code>header.png</code> con nuevo contenido), se debe cambiar el contenido del archivo de manifiesto para que los navegadores sepan que se necesita actualizar el caché. Se puede hacer cualquier cambio al archivo de manifiesto, pero cambiar el número de versión es una práctica recomendada.</p>
  <div class="warning">
    <strong>Importante:</strong> No hay que especificar el manifiesto en el mismo archivo de manifiesto Do not specify the manifest, porque sería casi imposible informar al navegador que hay un nuevo manifiesto disponible.</div>
  <h3 id="Secciones_en_un_archivo_de_manifiesto_de_cach.C3.A9.3A.C2.A0CACHE.2C.C2.A0NETWORK_y_FALLBACK">Secciones en un archivo de manifiesto de caché:&nbsp;<code>CACHE</code>,&nbsp;<code>NETWORK</code> y <code>FALLBACK</code></h3>
  <p>Un manifiesto puede tener tres secciones distintas:&nbsp;<code>CACHE</code>,&nbsp;<code>NETWORK</code> y <code>FALLBACK</code>.</p>
  <dl>
    <dt>
      <code>CACHE:</code></dt>
    <dd>
      Esta es la sección predeterminada para las entradas en el archivo de manifiesto de caché. Los archivos listados bajo el encabezado de sección <code>CACHE:</code> (o inmediatamente después de la línea <code>CACHE MANIFEST</code>) son guardados en caché explícitamente después de ser descargados la primera vez.</dd>
    <dt>
      <code>NETWORK:</code></dt>
    <dd>
      Los archivos listados bajo el encabezado de sección <code>NETWORK:</code> en el archivo de manifiesto de caché son recursos en <em>lista blanca</em> que requieren una conexión al servidor. Todos los pedidos a esos recursos evitan el caché aunque el usuario esté desconectado. Se pueden usar comodines.</dd>
    <dt>
      <code>FALLBACK:</code></dt>
    <dd>
      La sección <code>FALLBACK:</code> especifica las páginas que el navegador debería usar si un recurso no es accesible. Cada entrada en esta sección lista dos URIs—lla primera es el recurso, la seguda es el fallback. Ambas URIs deben ser relativas y del mismo origen que el archivo de manifiesto. Se pueden usar comodines.</dd>
  </dl>
  <p>Las secciones <code>CACHE</code>,&nbsp;<code>NETWORK</code> y <code>FALLBACK </code>pueden lsitarse en cualquier orden en el archivo de manifiesto y cada sección puede aparecer más de una vez en un manifiesto.</p>
  <h3 id="Ejemplo_2.3A_un_archivo_de_manifiesto_de_cach.C3.A9_m.C3.A1s_completo">Ejemplo 2: un archivo de manifiesto de caché más completo</h3>
  <p>El siguiente es un archivo de manifiesto de caché para el sitio web imaginario en <span class="nowiki">www.ejemplo.com</span>:</p>
  <pre class="eval">
CACHE MANIFEST
# v1 2011-08-14
# Este es otro comentario
index.html
cache.html
style.css
image1.png

# Usar desde la red si está disponible
NETWORK:
network.html

# Contenido de fallback
FALLBACK:
/ fallback.html
</pre>
  <p>Este ejemplo usa las secciones <code>NETWORK</code> y <code>FALLBACK</code> para especificar la página <code>network.html</code> que deber ser recuperada desde la red y que la página <code>fallback.html</code> servirá como fallback (ej. en caso que una conexión al servidor no pueda establecerse).</p>
  <h3 id="Estructura_de_un_archivo_de_manifiesto_de_cach.C3.A9">Estructura de un archivo de manifiesto de caché</h3>
  <p>Los archivos de manifiesto de caché deben enviarse con el tipo MIME <code>text/cache-manifest</code>. Todos los recursos servidos usando este tipo MIME deben seguir la sintaxis para un manifiesto de caché de aplicación, como se define en esta sección.</p>
  <p>Los manifiestos de caché son archivos de texto en formato UTF-8 y pueden incluír opcionalmente un caracter BOM. Las nuevas líneas pueden ser representadas por salto de línea (<code>U+000A</code>), retorno de carro (<code>U+000D</code>) o ambos retorno de carro y salto de línea.</p>
  <p>La primera línea del manifiesto de caché debe consistir en la cadena <code>CACHE MANIFEST</code>&nbsp;(con un solo espacio <code>U+0020</code> entre ambas palabras), seguido de cero o más espacios co caracteres de tabulación. Cualquier otro texto en la línea es ignorado.</p>
  <p>El resto del manifiesto de caché debe estar compuesto por cero o más de las siguientes líneas:</p>
  <dl>
    <dt>
      Línea en blanco</dt>
    <dd>
      Se pueden usar líneas en blanco compuestas por cero o más espacios y caracteres de tabulación.</dd>
    <dt>
      Comentario</dt>
    <dd>
      Los comentarios consisten en cero o más tabulaciones o espacios seguidos pur un caracter <code>#</code> seguido de cero o más caracteres del texto del comentario. Los comentarios pueden usarse solamente en sus propias líneas y no pueden agregarse a otras líneas. Esto significa que no puede espcificar identificadores de fragmento.</dd>
    <dt>
      Encabezado de sección</dt>
    <dd>
      Los encabezados de sección especifican qué sección del manifiesto de caché está siendo manipulada. Hay tres encabezados de sección posibles:</dd>
  </dl>
  <blockquote>
    <table class="standard-table">
      <tbody>
        <tr>
          <th>Encabezado de sección</th>
          <th>Descripción</th>
        </tr>
        <tr>
          <td><code>CACHE:</code></td>
          <td>Cambia a la sección explícita del manifiesto de caché (esta es la sección predeterminada).</td>
        </tr>
        <tr>
          <td><code>NETWORK:</code></td>
          <td>Cambia a la sección de lista blanca del manifiesto de caché.</td>
        </tr>
        <tr>
          <td><code>FALLBACK:</code></td>
          <td>Cambia a la sección fallback del manifiesto de caché.</td>
        </tr>
      </tbody>
    </table>
  </blockquote>
  <dl>
    <dd>
      La líena de encabezado de sección puede incluir espacios en blanco, pero debe incluir los dos puntos (<code>:</code>) en el nombre de sección.</dd>
    <dt>
      Datos de sección</dt>
    <dd>
      El formato de las líneas de datos varía de sección a sección. En la sección explícita (<code>CACHE:</code>), cada línea es una URI o referencia IRI a un recurso a guardar en caché (no se permiten caracteres comodines en esta sección). El espacio en blanco se permite antes y después de la URI o IRI en cada línea. En la sección Fallback cada línea es una URI o referencia IRI válida a un recurso, seguida por un recurso de fallback que será enviado cuando la comunicación con el servidor no pueda establecerse. En la sección Network, cada línea es una URI o referencia IRI válida a un recurso a obtener desde la red (se permite el caracter comodín * en esta sección).<br />
      <div class="note">
        <strong>Nota: </strong>URIs relativas son relativas a la URI del manifiesto de caché, no a la URI del documento que hace referencia al manifiesto.</div>
    </dd>
  </dl>
  <p>Los archivos de manifiesto de caché pueden cambiar de sección a sección a voluntad (cada encabezado de sección puede usarse más de una vez) y se permite que las secciones estén vacías.</p>
  <h2 id="Recursos_en_un_cach.C3.A9_de_aplicaci.C3.B3n">Recursos en un caché de aplicación</h2>
  <p>Un caché de aplicación siempre incluye al menos un recurso, identificado por URI. Todos los recursos entran en una de las siguientes categorías:</p>
  <dl>
    <dt>
      Entradas maestras</dt>
    <dd>
      Estos son recursos adicionados al caché porque un contexto de navegación visitado por el usuario incluyó un documento que indicó que estaba en caché usando el atributo <code>manifest</code>.</dd>
    <dt>
      Entradas explícitas</dt>
    <dd>
      Estos recursos están listados explícitamente en el archivo de manifiesto de caché de la aplicación.</dd>
    <dt>
      Entradas de red</dt>
    <dd>
      Estos son recursos listados en el archivo de manifiesto de caché de la aplicación como entradas de red.</dd>
    <dt>
      Entradas de fallback</dt>
    <dd>
      Estos son recursos listados en el archivo de manifiesto de caché de la aplicación como entradas de fallback.</dd>
  </dl>
  <div class="note">
    <strong>Nota:</strong> Los recursos pueden estar etiquetados en múltiples categorías y por lo tanto ser categorizados como entradas múltiples.&nbsp; Por ejemplo, una entrada puede ser explícita y fallback a la vez.</div>
  <p>Las categorías de recursos se describen con más detalle debajo.</p>
  <h3 id="Master_entries">Entradas maestras</h3>
  <p>Una entrada maestra es cualquier archivo HTML que incluya un atributo {{ htmlattrxref("manifest","html") }} en su elemento {{ HTMLElement("html") }}.&nbsp; Por ejemplo, digamos que tenemos el archivo <code><a class="linkification-ext external" href="http://www.foo.bar/entry.html" title="Linkification: http://www.foo.bar/entry.html">http://www.ejemplo.com/entrada.html</a></code>, que incluye el siguiente texto:</p>
  <pre class="brush: html">
&lt;html manifest="ejemplo.appcache"&gt;
  &lt;h1&gt;Ejemplo de cache de aplicacion&lt;/h1&gt;
&lt;/html&gt;
</pre>
  <p>Si <code>entrada.html</code> no esta listado en el archivo de manifiesto de cache <code>ejemplo.appcache</code>, visitar la pagina <code>entrada.html</code> causa que se agregue al cache de aplicacion el archivo <code>entrada.html</code> como entrada maestra.</p>
  <h3 id="Explicit_entries">Entradas explicitas</h3>
  <p>Las entradas explicitas son recursos que estan listados explicitamente en la seccion <code>CACHE </code>de un archivo de manifiesto de cache.</p>
  <h3 id="Network_entries">Entradas de red</h3>
  <p>La seccion <code>NETWORK</code> de un archivo de manifiesto de cache especifica recurso para los cuales una aplicacion web requiere acceso a internet. Las entradas de red en el cache de aplicacion son escencialmente una "lista blanca online"—URIs especificadas en la seccion <code>NETWORK</code> se cargaran desde el servidor en lugar del cache. Esto permite que el modelo de seguridad del navegador proteja al usuario de problemas de seguridad potenciales al limitar el acceso a recursos aprobados.</p>
  <p>Como ejemplo, puede usar entradas en la seccion red para cargar y ejecutar scripts y otro codigo desde el servidor en lugar del cache:</p>
  <pre>
CACHE MANIFEST
NETWORK:
/api
</pre>
  <p>The cache manifest section listed above ensures that requests to load resources contained in the&nbsp;<code><a class="external" href="http://www.example.com/api/" rel="freelink">http://www.example.com/api/</a></code>&nbsp;subtree always go to the network without attempting to access the cache.</p>
  <div class="note">
    <strong>Note</strong>:&nbsp;Simply omitting master entries (files that have the&nbsp;<code>manifest</code>&nbsp;attribute set in the&nbsp;<code>html</code>&nbsp;element) from the manifest file would not have the same result, because master entries will be added—and subsequently served from—the application cache.&nbsp;</div>
  <h3 id="Fallback_entries">Fallback entries</h3>
  <p>Fallback entries are used when an attempt to load a resource fails.&nbsp; For example, let's say the cache manifest file&nbsp;<code><a class="external" href="http://www.example.com/example.appcache" rel="freelink">http://www.example.com/example.appcache</a></code>&nbsp;includes the following content:</p>
  <pre>
CACHE MANIFEST
FALLBACK:
example/bar/ example.html
</pre>
  <p>Any request to&nbsp;<code><a class="external" href="http://www.example.com/example/bar/" rel="freelink">http://www.example.com/example/bar/</a></code>&nbsp;or any of its subdirectories and their content cause the browser to issue a network request to attempt to load the requested resource.&nbsp; If the attempt fails, due to either a network failure or a server error of some kind, the browser loads the file&nbsp;<code>example.html</code>&nbsp;instead.</p>
  <h2 id="Cache_states">Cache states</h2>
  <p>Each application cache has a&nbsp;<strong>state</strong>, which indicates the current condition of the cache.&nbsp; Caches that share the same manifest URI share the same cache state, which can be one of the following:</p>
  <dl>
    <dt>
      <code>UNCACHED</code></dt>
    <dd>
      A special value that indicates that an application cache object is not fully initialized.</dd>
    <dt>
      <code>IDLE</code></dt>
    <dd>
      The application cache is not currently in the process of being updated.</dd>
    <dt>
      <code>CHECKING</code></dt>
    <dd>
      The manifest is being fetched and checked for updates.</dd>
    <dt>
      <code>DOWNLOADING</code></dt>
    <dd>
      Resources are being downloaded to be added to the cache, due to a changed resource manifest.</dd>
    <dt>
      <code>UPDATEREADY</code></dt>
    <dd>
      There is a new version of the application cache available.&nbsp; There is a corresponding&nbsp;<code>updateready</code>&nbsp;event, which is fired instead of the&nbsp;<code>cached</code>&nbsp;event when a new update has been downloaded but not yet activated using the&nbsp;<code>swapCache()</code>&nbsp;method.</dd>
    <dt>
      <code>OBSOLETE</code></dt>
    <dd>
      The application cache group is now obsolete.</dd>
  </dl>
  <h2 id="Testing_for_updates_to_the_cache_manifest">Testing for updates to the cache manifest</h2>
  <p>You can programmatically test to see if an application has an updated cache manifest file, using JavaScript. Since a cache manifest file may have been updated before a script attaches event listeners to test for updates, scripts should always test&nbsp;<code>window.applicationCache.status</code>.</p>
  <pre class="brush: js">
function onUpdateReady()&nbsp;{
&nbsp;&nbsp;alert('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
&nbsp;&nbsp;onUpdateReady();
}</pre>
  <p>&nbsp;To manually start testing for a new manifest file, you can use&nbsp;<code>window.applicationCache.update()</code>.</p>
  <h2 id="Gotchas">Gotchas</h2>
  <ul>
    <li>Never access cached files by using traditional GET parameters (like <code>other-cached-page.html?parameterName=value</code>). 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 <code>other-cached-page.html#whatever?parameterName=value</code>.</li>
    <li>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&nbsp;<code>window.applicationCache.swapCache()</code>, 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.</li>
    <li>It's a good idea to set expires headers on your web server for&nbsp;<code>*.appcache</code>&nbsp;files to expire immediately. This avoids the risk of caching manifest files. For example, in Apache you can specify such a configuration as follows:<br />
      <code>ExpiresByType text/cache-manifest "access plus 0 seconds"</code></li>
  </ul>
  <h2 id="Browser_Compatibility">Browser Compatibility</h2>
  <p>{{ CompatibilityTable() }}</p>
  <div id="compat-desktop">
    <table class="compat-table">
      <tbody>
        <tr>
          <th>Feature</th>
          <th>Chrome</th>
          <th>Firefox (Gecko)</th>
          <th>Internet Explorer</th>
          <th>Opera</th>
          <th>Safari</th>
        </tr>
        <tr>
          <td>Basic support</td>
          <td>4.0</td>
          <td>3.5</td>
          <td>10.0</td>
          <td>10.6</td>
          <td>4.0</td>
        </tr>
      </tbody>
    </table>
  </div>
  <div id="compat-mobile">
    <table class="compat-table">
      <tbody>
        <tr>
          <th>Feature</th>
          <th>Android</th>
          <th>Firefox Mobile (Gecko)</th>
          <th>IE Mobile</th>
          <th>Opera Mobile</th>
          <th>Safari Mobile</th>
        </tr>
        <tr>
          <td>Basic support</td>
          <td>2.1</td>
          <td>{{ CompatVersionUnknown() }}</td>
          <td>{{ CompatNo() }}</td>
          <td>11.0</td>
          <td>3.2</td>
        </tr>
      </tbody>
    </table>
  </div>
  <p>Note: Versions of Firefox prior to 3.5 ignore the&nbsp;<code>NETWORK&nbsp;</code>and&nbsp;<code>FALLBACK&nbsp;</code>sections of the cache manifest file.</p>
  <h2 id="See_also">See also</h2>
  <ul>
    <li><a class="external" href="http://www.html5rocks.com/en/tutorials/appcache/beginner/" title="http://www.html5rocks.com/en/tutorials/appcache/beginner/">HTML5Rocks - A Beginner's Guide to Using the Application Cache</a></li>
    <li><a class="external" href="http://appcachefacts.info/" title="http://appcachefacts.info/">appcachefacts.info</a>&nbsp;- detailed information on AppCache idiosyncrasies</li>
    <li><a class="external" href="http://hacks.mozilla.org/2010/01/offline-web-applications/" title="http://hacks.mozilla.org/2010/01/offline-web-applications/">offline web applications</a>&nbsp;at hacks.mozilla.org - showcases an offline app demo and explains how it works.</li>
    <li><a class="external" href="http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline" title="http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline">HTML 5 working draft: Offline web applications</a></li>
    <li><a class="external" href="http://developer.teradata.com/blog/js186040/2011/11/html5-cache-manifest-an-off-label-usage" title="http://developer.teradata.com/blog/js186040/2011/11/html5-cache-manifest-an-off-label-usage">HTML5 Cache Manifest: An Off-label Usage</a></li>
    <li>{{ interface("nsIApplicationCache") }}</li>
    <li>{{ interface("nsIApplicationCacheNamespace") }}</li>
    <li>{{ interface("nsIApplicationCacheContainer") }}</li>
    <li>{{ interface("nsIApplicationCacheChannel") }}</li>
    <li>{{ interface("nsIApplicationCacheService") }}</li>
    <li>{{ interface("nsIDOMOfflineResourceList") }}</li>
    <li><a class="external" href="http://www.ibm.com/developerworks/web/library/wa-ffox3/">Get ready for Firefox 3.0 - A Web developer's guide to the many new features in this popular browser, especially the offline application features</a>&nbsp;(IBM developerWorks)</li>
  </ul>
  <p>{{ HTML5ArticleTOC() }}</p>
</div>
<p>&nbsp;</p>
Revertir a esta revisión