Question

It seems that once you have a manifest entry, a la:

<html manifest="cache.manifest">

Then that page (the master entry in the cache) will always be cached (at least by Safari) until the user does something to remove the cache, even if you later remove the manifest attribute from the html tag and update the manifest (by changing something within it), forcing the master entry to be reloaded along with everything else.

In other words, if you have:

  • index.html (with manifest defined)
  • file1.js (referenced in manifest)
  • file2.js (referenced in manifest)
  • cache.manifest (lists the two js files)

-- removing the manifest entry from index.html and modifying the manifest (so it gets expired by the browser and all content reloaded) will not stop this page from behaving as if it's still fully cached. If you view source on index.html you won't see the manifest listed anymore, but the browser will still request only the cache.manifest file, and unless that file's content is changed, no other changes to any files will be shown to the user.

It seems like a pretty glaring bug, and it's present on iOS as well as Mac versions of Safari. Has anyone found a way of resetting the page and getting rid of the cache without requiring user intervention?

Was it helpful?

Solution

Ive been researching the same question, and it doesnt appear to be an api to:

  1. dynamically trigger that a page is cached
  2. dynamically cause a page to stop being cached.

Here are the best resources I have found:

http://www.html5rocks.com/tutorials/appcache/beginner/

http://www.thecssninja.com/javascript/how-to-create-offline-webapps-on-the-iphone

In particular, this quote from the first link:

If the manifest file or a resource specified in it fails to download, the entire update fails. The browser will continue to use the old application cache in the event of such a failure.

Otherwise, there is no mention anywhere about unloading the cache.

Seems to suggest that you cant force an error to get it to uncache. However, as noted below, the spec suggests that if an error occurs while downloading the manifest file, the entire cache will be removed.

In google chrome, the user can go to the following URL:

chrome://appcache-internals/

And manually disable the cache. Of course, the next time they visit the page, it will be recached if the page has the manifest property set.

If you look at the specification:5.6 Offline Web applications

It seems to suggest a situation where the cache is removed. Specifically, section 5.6.4.5:

If fetching the manifest fails due to a 404 or 410 response or equivalent, then run these substeps: Mark cache group as obsolete. This cache group no longer exists for any purpose other than the processing of Document objects already associated with an application cache in the cache group. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

It then says:

If this was a cache attempt, discard cache group altogether.

Basically, if the request for the cache manifest file results in a 404, then the entire cache should be discarded. So, have you tried to have the server return a 404 or 410 when the cache manifest file is requested? That should work. The trick is to only return the 404 / 410 for the pages you want to remove the manifest from (perhaps using url parameters?).

OTHER TIPS

One possible solution:

  • modify the manifest (so it reloads)
  • modify the master file (index.html) to reference a non-existant manifest, so it gets a 404

Hardly elegant, but it seems to work. The main problem then is that you're stuck with this 404-generating false manifest entry until everyone who has ever been to your site has returned and had their cache cleared.

There has got to be a better way...

Try to simply delete the manifest file. From the mozzila docs :

Application caches can also become obsolete. If the manifest is removed from the server, the browser removes all application caches that use that manifest, then sends an "obsoleted" event to the application cache object. Then the application cache's status is set to OBSOLETE.

This also worked for me on chrome.

One solution, if you are using IIS 7 is to remove the Mime Type for the .manifest or .appcache file type that you added to enable caching. You can always add this back when you want to enable caching again. This is what I did to fix mine.

What we do is delete the list of files in the manifest, so it stands out NO file will be cached.

It works for us.

This might be old but hopefully still helpful to someone.

Take a look at your HTTP headers in IIS properties. Take a look at enabling or disabling content expiration. It might be that IIS is still doing the cache.

For development purposes (constant changes), what we have done is:

  1. Set a -cache manifest file- under your SERVER-SIDE language, for example, we use PHP, so our development cache is called "cache.manifest.php" and it's pointed this same way in the html tag like this:

    <html manifest="cache.manifest.php">
    
  2. Put some -time dependent- string (or something else that suites you) somewhere in your manifest as a comment (#---), so that the file is different every once in a while (browsers seem to compare manifest's content, not date), for example this string changes the manifest every minute, this way all files would be re-cached if the visit is in a different minute as the last time.

    <?php if($dev) echo date("Y-m-d H:m"); ?>
    

We've just tested this procedure using Chrome, hope it works in others, but if not your comments and advices would be very well appreciated.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top