[Bug 13168] New: Creating or using an existing application cache without caching the master entry

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13168

           Summary: Creating or using an existing application cache
                    without caching the master entry
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://dev.w3.org/html5/spec/history.html#navigating-a
                    cross-documents
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: adrianba@microsoft.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, israelh@microsoft.com


PROBLEM
-------
Many sites generate a onetime page that they don�t 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 won�t 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 won�t 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 resource�s 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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 7 July 2011 04:32:47 UTC