PROBLEM
-------
Many sites share the same manifest file for their pages. The first time one of these pages is downloaded, an application cache inside a cache group is created.  The application cache contains the URLs of the pages that point to the manifest URL (i.e. master resource).
When a new page that points to the same manifest file is encountered, all of its resources will be accessed from the network because there is no master entry in the application cache. At a later time, when the page is loaded and the manifest entry verified, the page is added to the list of master entries in the application cache.
We want to eliminate the network accessed for pages that can be mapped to an existing application cache via their manifest URL.  To increase performance and reduce server load, we want these pages to use the resources in local application cache.  After this takes place, we want the regular application cache download process to be initiated.

PROPOSED SPEC CHANGES [MSFT]
---------------------
Spec Location: http://dev.w3.org/html5/spec/offline.html#downloading-or-updating-an-application-cache

5.6.5 The application cache selection algorithm
When the application cache selection algorithm algorithm is invoked with a Document document and optionally a manifest URL manifest URL, the user agent must run the first applicable set of steps from the following list:

    * If there is a manifest URL, and document was loaded from an application cache, and the URL of the manifest of that cache's application cache group is not the same as manifest URL
Mark the entry for the resource from which document was taken in the application cache from which it was loaded as foreign.
Restart the current navigation from the top of the navigation algorithm, undoing any changes that were made as part of the initial load (changes can be avoided by ensuring that the step to update the session history with the new page is only ever completed after this application cache selection algorithm is run, though this is not required).
The navigation will not result in the same resource being loaded, because "foreign" entries are never picked during navigation.
User agents may notify the user of the inconsistency between the cache manifest and the document's own metadata, to aid in application development.

    * If document was loaded from an application cache, and that application cache still exists (it is not now obsolete)
Associate document with the application cache from which it was loaded. Invoke, in the background, the application cache download process for that application cache's application cache group, with document as the cache host.

[MSFT]
--> * If document was loaded using HTTP GET or equivalent, the document contains a manifest URL, manifest URL has the same origin as document, and there exists an application cache that matches manifest URL but there is no master entry for the document in the application cache group (application cache is not now obsolete)
-->      Associate document with the application cache that matches manifest URL. Invoke, in the background, the application cache download process for that application cache's application cache group, with document as the cache host. (This will be treated as an update event).

    * If document was loaded using HTTP GET or equivalent, and, there is a manifest URL, and manifest URL has the same origin as document
Invoke, in the background, the application cache download process for manifest URL, with document as the cache host and with the resource from which document was parsed as the master resource.
 
    * Otherwise
The Document is not associated with any application cache.
If there was a manifest URL, the user agent may report to the user that it was ignored, to aid in application development