This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13168 - Creating or using an existing application cache without caching the master entry
Summary: Creating or using an existing application cache without caching the master entry
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/history....
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-07 04:32 UTC by Adrian Bateman [MSFT]
Modified: 2011-11-22 22:17 UTC (History)
6 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2011-07-07 04:32:37 UTC
PROBLEM
-------
Many sites generate a onetime page that they dont want cache on the client machine.  This information contains user specific information that is only good for a brief timeframe (e.g. session).  However, they would like to take advantage of application caches to reduce server loads and increase performance by defining a group of static resources that they would like to cache locally.
The first time one of these pages is accessed, an application cache inside a cache group is created using the information in the manifest attributes.  However, the newly created application cache wont contain a master entry for that page (i.e. the page that contains the manifest URL). This behavior change will be specified via a new section inside manifest file.
The next time another page with the same manifest URL is accessed, the page itself will be downloaded from the network but its resources will be accessed from the previously created application cache.  Again, no master entry will be created for that page inside the application cache.
After the existing cache is associated with the page being displayed, the application cache download will be initiated in the background.  This will ensure the latest application cache is always being used.  Because of the new semantics specified in the manifest file, the application cache will have the master entries associated with it but the master entry content wont be cached.
Specifying this new mode, MASTER: with a value of [NETWORK] will prevent any master entries from being cached in the application cache.  Anything else under MASTER: will ignore.

EXAMPLE MANIFEST FILE
---------------------
CACHE MANIFEST
#Version 1

MASTER:
[NETWORK]

CACHE:
images/amazon.png

FALLBACK:
images/ images/stop.png

NETWORK:
images/off.png

PROPOSED SPEC CHANGES [MSFT]
---------------------
Spec Location: http://dev.w3.org/html5/spec/offline.html#manifests

5.6.3.3 Parsing cache manifests
[MSFT]
--> 6.5        Let the master entry cache flag be true.

20. If line equals "FALLBACK:" (the word "FALLBACK" followed by a U+003A COLON character (:)), then set mode to "fallback" and jump back to the step labeled "start of line".
21. If line equals "NETWORK:" (the word "NETWORK" followed by a U+003A COLON character (:)), then set mode to "online whitelist" and jump back to the step labeled "start of line".
[MSFT]
-->22. If line equals "MASTER:" (the word "MASTER" followed by a U+003A COLON character (:)), then set mode to "master" and jump back to the step labeled "start of line".
23. If line ends with a U+003A COLON character (:), then set mode to "unknown" and jump back to the step labeled "start of line".

28. Process tokens as follows:

  If mode is "explicit"
  Resolve the first item in tokens, relative to base URL; ignore the rest.
  If this fails, then jump back to the step labeled "start of line".
  If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line". If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, and the resulting absolute URL does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".
  Drop the <fragment> component of the resulting absolute URL, if it has one.
  Add the resulting absolute URL to the explicit URLs.

  If mode is "fallback"
  Let part one be the first token in tokens, and let part two be the second token in tokens.
  Resolve part one and part two, relative to base URL.
  If either fails, then jump back to the step labeled "start of line".
  If the absolute URL corresponding to either part one or part two does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".
  Drop any <fragment> components of the resulting absolute URLs.
  If the absolute URL corresponding to part one is already in the fallback URLs mapping as a fallback namespace, then jump back to the step labeled "start of line".
  Otherwise, add the absolute URL corresponding to part one to the fallback URLs mapping as a fallback namespace, mapped to the absolute URL corresponding to part two as the fallback entry.

[MSFT]
-->If mode is "master"
-->If the first line in tokens equals [NETWORK] (the word [NETWORK] followed by end of line U+ 000D, then set master entry cache flag to false, then jump back to the step labeled "start of line".  Else, jump back to the step labeled "start of line".
-->[NETWORK] is the only valid entry in this mode.

  If mode is "online whitelist"
  If the first item in tokens is a U+002A ASTERISK character (*), then set online whitelist wildcard flag to open and jump back to the step labeled "start of line".
  Otherwise, resolve the first item in tokens, relative to base URL; ignore the rest.
  If this fails, then jump back to the step labeled "start of line".
  If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".
  Drop the <fragment> component of the resulting absolute URL, if it has one.
  Add the resulting absolute URL to the online whitelist namespaces.

  If mode is "unknown"
  Do nothing. The line is ignored.

[MSFT]
-->30. When the master entry cache flag  is set to true, the resource that declares the manifest (with the manifest attribute) will always get taken from the cache, whether it is listed in the cache or not, even if it is listed in an online whitelist namespace.

5.6.4 Downloading or updating an application cache
7. If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in the newest application cache in cache group, or the server reported it as "304 Not Modified" or equivalent, then run these substeps:
  1. Let cache be the newest application cache in cache group.
  2. Let task list be an empty list of tasks.
  3. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.
     
     If the download failed (e.g. the connection times out, or the user cancels the download), then create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host the Document for this entry, if there still is one, and append it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.
     
[MSFT]
--> Otherwise, if the master entry cache flag is set to true, associate the Document for this entry with cache; store the resource for this entry in cache, if it isn't already there, and categorize its entry as a master entry. If the resource's URL has a <fragment> component, it must be removed from the entry in cache (application caches never include fragment identifiers).
--> Else if the master entry cache flag is set to false, associate the Document for this entry with cache; do not store the resource for this entry in cache.

    HTTP caching rules, such as Cache-Control: no-store, are ignored for the purposes of the application cache download process.
17. For each URL in file list, run the following steps. These steps may be run in parallel for two or more of the URLs at a time.
[MSFT]
--> 1. If the resource URL being processed was flagged as a master entry with master entry cache flag then the user agent needs to skip this URL.
    2. If the resource URL being processed was flagged as neither an "explicit entry" nor or a "fallback entry", then the user agent may skip this URL.

[MSFT] 
-->22. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.  All these pending master entries will have the same master entry cache flag of true.

5.6.6 Changes to the networking model
[MSFT]
--> 2. If the resource's URL is a master entry with a master entry cache flag of true, the manifest, an explicit entry, or a fallback entry in the application cache, then get the resource from the cache (instead of fetching it), and abort these steps.
--> 2.5 If the resources URL is a master entry with a master entry cache flag of false, then fetch the resource normally and abort these steps.


ADDITIONAL
----------
Additional changes to this other spec may be required:

http://dev.w3.org/html5/spec/history.html#navigating-across-documents
5.5.1 Navigating across documents
  13. If the resource has already been obtained (e.g. because it is being used to populate an object element's new child browsing context), then skip this step.

      Otherwise:
[MSFT]
-->   If the new resource is to be fetched using HTTP GET or equivalent, and there are relevant application caches that are identified by a URL with the same origin as the URL in question, and that have this URL as one of their entries, excluding entries marked as foreign or entries with a master entry cache flag of false, then get the resource from the most appropriate application cache of those that match.
Comment 1 Michael[tm] Smith 2011-08-04 05:02:01 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-10 00:52:07 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: If you don't need the page to be accessible while offline, which you presumably don't in the given use case, then using a manifest is pointless: you can just rely on the regular HTTP cache.