Recursos en modo desconectado en Firefox

Firefox 3 implementa en gran parte el soporte HTML 5 para la memoria cache (memoria temporal) de la aplicación web en modo desconectado. Esto lo hace por medio del cache de la aplicación (un conjunto de recursos obtenido con un manifiesto proporcionado por la aplicación web).

El cache de la aplicación

Nota: Firefox no gestiona actualmente ningún control de versión en el cache de aplicación.

Ya que múltiples aplicaciones web pueden compartir recursos (y pueden incluso compartir la misma URI) cada aplicación mantiene su propio cache (su propia memoria temporal). Sin embargo, las diferentes cache de las aplicaciones son agrupadas por su propio manifiesto de usuario y tienen un estado de actualización conjunto. El estado de actualización es uno de los siguientes:

idle: El cache de aplicación no está descargando actualizaciones.
checking: El cache está comprobando su propio manifiesto de recursos, para ver si hay uno más reciente.
downloading: El cache está actualizando su manifiesto de recursos con información nueva, ya que el anterior fue modificado.

Nota sobre Firefox 3

Actualmente, sólo se permiten estradas de recursos. Firefox no admite aún cambios oportunistas o entradas de restitución (volver a versiones anteriores), sin embargo, es recomendable suministrar una lista blanca, si procede, para una compatibilidad futura.

Recursos

El cache siempre incluye al menos un recurso, identificado por su URI, de al menos una de las siguientes categorías:

Entradas implícitas (Implicit entries): Son recursos agregados al cache por que un contexto de navegación principal visitado por el usuario incluyó un documento que indica que el recurso está en su cache, utilizando su atributo manifest.
El manifiesto (manifest): Este es el manifiesto de recurso en sí mismo, cargado desde la URI especificada en una entrada de html implícita con el atributo manifest. El manifiesto es descargado y tratado durante el proceso de actualización del cache de la aplicación. Las entradas implícitas han de tener el mismo protocolo, servidor y puerto que el manifiesto.
Entradas explícitas (Explicit entries): Son recursos listados en el manifiesto del cache.
Entradas de restitución/recuperación (Fallback entries): Son recursos que fueron listados en el manifiesto del cache como entradas "fallback". No admitido aún en Firefox.
Entradas oportunistas (Opportunistically cached entries): Son recursos cuyas URI correspondían a un espacio de nombre de puesta en cache oportunista cuando se descargaron y que por tanto, fueron puestas automáticamente en la memoria de la aplicación. No admitido aún en Firefox.
Entradas dinámicas (Dynamic entries): Son recursos añadidos por programa, con el método add().

La lista blanca en línea

La lista blanca puede contener cero o más URIs de recursos, que la aplicación web necesitará obtener del servidor en lugar de desde la memoria cache. Esto permite al modelo de seguridad del navegador proteger al usuario de posibles brechas de seguridad, limitando el acceso sólo a recursos aprobados.

Nota: La lista blanca no se usa en Firefox 3, sin embargo, convendría facilitar una si se necesita, tanto para tener y/o mantener la compatibilidad con versiones futuras de Firefox u otros navegadores que implementen recursos en modo desconectado.

El manifiesto

Los archivos de manifiesto deben darse con el tipo MIME text/cache-manifest, y todos los recursos entregados con este tipo MIME deben seguir la sintaxis para un manifiesto de aplicación cache, según se define más abajo. Los manifiestos de cache son archivo de texto con formato 'UTF-8' y pueden, opcionalmente, incluir un carácter BOM. Las líneas nuevas pueden ser representadas por un carácter de nueva linea (U+000A) o por uno de retorno de carro (U+000D) o por ambos caracteres.

La primera línea de un manifiesto cache debe contener la cadena de orden: "CACHE MANIFEST" (con un espacio simple U´0020 entre las dos palabras), seguido por nada, espacios o caracteres de tabulador. Cualquier otro texto en esta línea será ignorado.

El resto del manifiesto debe estar compuesto por ninguna , alguna o todas las líneas siguientes:

Línea vacía: Podemos utilizar líneas vacías (sin nada) o con caracteres de espacio o tabulador.
Comentario: Los comentarios son formados por un sólo carácter "#", seguido por nada o con el texto del comentario, si se quiere se puede poner espacio/s antes (por ejemplo: # Aquí va mi comentario ). Los comentarios sólo se pueden escribir en sus propias líneas y no se pueden añadir en otras líneas.
Cabecera de sección: Las cabeceras de sección especifican qué sección del manifiesto se está manipulando. Hay tres posibles cabeceras de sección:

Cabecera de sección Descripción

CACHE: Pasa a la sección explícita. Esta es la sección por defecto.

FALLBACK: Pasa a la sección de recuperación ("fallback").
Nota: Esta sección no está aún implementada en Firefox y será ignorada.

NETWORK: Pasa a la sección de la lista blanca en línea.
Nota: La sección de lista blanca en línea, no está aún implementada en Firefox y será ignorada, sin embargo, suministrar una lista blanca apropiada está fuertemente recomendado.

Cabecera de sección	Descripción
`CACHE:`	Pasa a la sección explícita. Esta es la sección por defecto.
`FALLBACK:`	Pasa a la sección de recuperación ("fallback"). Nota: Esta sección no está aún implementada en Firefox y será ignorada.
`NETWORK:`	Pasa a la sección de la lista blanca en línea. Nota: La sección de lista blanca en línea, no está aún implementada en Firefox y será ignorada, sin embargo, suministrar una lista blanca apropiada está fuertemente recomendado.

La línea de cabecera de sección puede contener espacios vacíos, pero es obligatorio incluir el carácter ":" después del nombre.
Datos para la sección activa.: El formato de las líneas de datos cambia de sección a sección. En la sección explícita, cada línea es una URI válida o referencia IRI a un recurso del cache. Los espacios vacíos están permitidos antes y después de la URI o IRI en cada línea.

El manifiesto puede pasar de atrás a delante de sección a sección como quiere (de modo que cada cabecera de sección se puede usar más de una vez) y las secciones pueden estar vacías.

Nota: Las URI relativas son relativas a la URI del manifiesto del cache, no a la URI del documento que referencia el manifiesto.

Un manifiesto de ejemplo

Este es un manifiesto simple para una página web imaginaria cuyo sitio es foo.com.

CACHE MANIFEST
# v1
# Esto es un comentario.
https://www.foo.com/index.html
https://www.foo.com/header.png
https://www.foo.com/blah/blah

En este ejemplo, no hay cabecera de sección, por lo que se considera que todas las líneas de datos están en la sección explícita.

El comentario "v1" está ahí por una buena razón. Ya que el cache es actualizado sólo cuando el manifiesto cambia, si cambia el recurso (por ejemplo, actualizando la imagen header.png con nuevo contenido), el archivo del manifiesto debe modificarse para advertir el navegador que necesita refrescar el cache. Se puede hacer con cualquier truco en el manifiesto, pero tener un número de versión es una buena forma de hacerlo.

Para indicar a Firefox que use aplicaciones en modo desconectado (almacenadas en el cache) para un sitio determinado, el sitio debe utilizar el atributo manifest en el elemento html, de forma parecida a:

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

El proceso de actualización

Cuando Firefox visita un documento que incluye el atributo manifest, envía un evento checking al objeto window.applicationCache, y a continuación recupera el archivo del manifiesto, siguiendo las reglas HTTP apropiadas. Si la copia actualmente en cache del manifiesto está al día, se envía el evento noupdate a la applicationCache, y el proceso de actualización está completado.
Si el archivo del manifiesto no ha cambiado desde la última actualización, de nuevo, se envía el evento noupdate a la applicationCache, y el proceso de actualización está completado. Esta es la razón por la que, si los recursos cambian, el archivo del manifiesto debe modificarse para que Firefox sepa que necesita refrescar la cache de recursos.
Si el manifiesto ha cambiado, todos los archivos en el manifiesto -- así como aquellos agregados al manifiesto mediante la llamada a applicationCache.add() -- son agregados al cache temporal, siguiendo las reglas apropiadas de HTTP. Para cada archivo agregado a la cache, se envía un evento progress al objeto applicationCache. Si ocurre algún error, se envía un evento error y se detiene la actualización.
Una vez que se han recuperado todos los archivos, son movidos al cache real y se envía un evento cached al objeto applicationCache.

Características aún sin implementar en Firefox

Debido a que el borrador estándar para HTML 5 estaba aún cambiando cuando llegamos a la fecha de congelación de características de Firefox 3, hay partes de las capacidades en modo desconectado que no han sido implementadas:

La especificación del WHATWG indica que todas las peticiones deben venir de la copia cache desconectada, cuando es posible, aún cuando el navegador esté conectado. Firefox sólo accede a la copia cache desconectada, cuando el navegador no está conectado. Por esta razón, la lista blanca tampoco está aún funcionando.
Firefox no mantiene actualmente copias cache separadas para las distintas aplicaciones. Las aplicaciones deberían evitar compartir recursos entre diferentes manifiestos, a no ser que no produzcan conflicto entre diferentes versiones de los recursos. En general, las aplicaciones deberían mantener copias separadas de cada recurso.
Firefox no gestiona aún entradas de recuperación o de oportunidad.