Bug 29182 – AppCache re-fetches the host page when the host page is not cached by the browser's main cache

• Status: UNCONFIRMED
• Component: New Bugs

[Andrew Grieve]

A summary of what happens when first visiting an page with a manifest is as follows:

1. Fetch the page
2. Fetch the manifest
3. Fetch resources on the page
4. Fetch all resources in the manifest

The host page is *always* a resource in the application cache, since even if it's not listed, it is added as in implicit entry. In step 4, it re-fetches the host page to put into the Application Cache, even though it has just been fetched. This is not so bad in the case where the host page was put into the browser's normal cache. However, if the page is served with no-cache headers, or if it is too big to be put into the normal cache (as is often the case on the iPhone), then the host page is fetched over the network for a second time.

The problem case should be optimized by having AppCache not fetch the host page over the network. Instead, the host page (and any other resources linked from it that are also listed in the manifest) should be put into AppCache as soon as they are downloaded the first time.

To test this behaviour, create a simple page that has an empty manifest and serve it with Cache-Control: no-cache and then watch what requests are made during page load.

[Andrew Grieve]

Update. After some further tests it looks like removing the host page's URL from the manifest causes it not to be downloaded twice on the initial fetch. This work-around works only for sites that have one top-level page associated with the manifest, and does not prevent other linked resources, such as JS and CSS from being downloaded twice.

[Mark Rowe (bdash)]

<rdar://problem/7217421>

[Alexey Proskuryakov]

Is there a practical reason to serve offline web application resources with Cache-Control: no-cache?