[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