I have noticed that a touch, or another modification of the manifest file's metadata will not trigger an update (at least when testing with Google Chrome). The browser will fire the noupdate event unless I change something more meaningful in the file, such as adding a line of whitespace.
How does the browser compare the old manifest against the new? Does it download the new manifest and compare it? Is it determined somehow from the file header?
http://diveintohtml5.info/offline.html includes a good explanation of the process that the browser follows when loading the manifest.
Briefly:
the server attempts to get a new copy of the manifest
if you have an old version, it will compare the content of the manifest file to the old manifest - so if your index page has changed, but you have no new files, it'll fire noupdate. Any change to the manifest contents, as trivial as adding whitespace (as you saw), will cause your listed assets to be redownloaded.
a common way to deal with this is to add a SHA or something as a comment to your manifest, generated in such a way that it'll change when any of the assets themselves change.
Related
I changed my cache.manifest file to the following:
CACHE MANIFEST
NETWORK:
*
CACHE:
FALLBACK:
This triggered an update to my site.
I tried adding a "#" to the manifest file and then removed the manifest="cache.manifest"from my page.
This triggered the cache to be updated again, even though the reference to the manifest was gone. The console indicated it was still being loaded from cache.
I even tried renaming my cache.manifest file and it still was being loaded from cache.
How in the world can I safely stop using cache manifest? I have a completely new version of my site I want to roll out, but if cache manifest is still trying to cache the new site, that will be a disaster for all my visitors who do not know they need to clear their browser cache.
I believe I found the trick.
It seems I need to keep the old cache.manifest but change (not remove) the reference to a non-existent manifest file.
Presumably, I'll need to keep the broken reference there for several years in case I have visitors who only visit periodically.
I know how to tell the browser to download cached fuiles again by simply changing a character in the appcache manifest, but when I do that, how can I make sure the browser downloads the new file without doing things like changing filenames?
I am aware of file expiration headers I can send, but I have no experience with them. Would they even work with HTML5 caching? Which ones do I send?
I'm under the impression that browsers aren't smart enough to detect when a file is modified, and will continue using the cached file until you force it by refreshing the page or changing the filename. I don't want to do that since it also means updating the manifest and is just extra work.
My optimal solution is to change the manifest slightly, then the browser goes and fetches any changed files without me forcing it to.
What I do is add the timestamp as a comment in the manifest
# 20130623 025200
And just update it each time I want to force a refresh.
EDIT: As I noted in the comments, The browser will re-download all files explicitly enumerated in the manifest. For files that are not in the manifest (for example, CSS or images referenced in an HTML file but not in the manifest), the default expiry take precedence.
The algorithm is described in the standard: http://www.w3.org/html/wg/drafts/html/master/browsers.html#downloading-or-updating-an-application-cache
It seems that if the cache manifest on the server changes it will re-download everything in file? Is there any way to only make it re-download some of the files? If I only make code fixes to a script and then update the manifest (say just put a timestamp comment in it) to force local copies to see a change has been made, I might not want images re-downloaded that haven't changed but still need to be in the manifest. Is there a way to get more precision around this or is it an all or nothing thing?
From what i've expreienced, updating the cache manifest doesn't explicitly download all the content again, but rather checks if they've been modified. So if there are 10 items in your cache manifest and you were to update a single file (and also the manifest file), then each file would be checked for modification, and depending on how they are being served (CDN?) they should be returning a 304 Not Modified, and thus not be downloaded again.
I'm using HTML5 appcache and mostly it's working well. However, sometimes, users' browsers (Chrome or Safari) will hold onto the cached manifest file even though I'm positive that the server has a brand new manifest file with a unique version number inside of a comment (like with "# app version 1.0.0.8" or whatever).
In IIS (version 6), the content expiration was set to 1 day, so could that be the problem? I can't seem to reproduce this issue which makes debugging difficult. As a precaution, in IIS I've changed the content expiration to "expire immediately" for the directory that stores the manifest file. Could that explain why some browsers were hanging onto manifest files even when a new version was available?
I also noticed that when a browser was behaving this way, even if I deleted the manifest file on the server, the user's browser would use its own cached copy of the manifest file which isn't supposed to happen if the file is no longer available in my understanding.
Thanks,
Andy
Taken from my answer here : https://stackoverflow.com/a/13282735/727575
Yes, this is the current "correct" behaviour. It has nothing to do with IIS content expiration. This is what happens:
When you just made changes to the manifest file, and you refresh the browser, this is what happens (assuming you're online)
the browser first loads back all the files in the cache
then the browser check online for your manifest file
it detects that the manifest file has changed, it will then proceed to download the new files
however, keep in mind, at this time, you will still be looking at your 'old files' because the browser has loaded the old files before going online to download the 'new files'
if at this point, if you hit refresh again (2nd time), you should get the 'new files'
This is currently the standard behaviour. Some people put some event handlers to prompt the user to do another refresh (after the 1st refresh)
So basically, you need to refresh twice or throw one of the event from 'window.applicationCache' to handle it
To look at an example of using window.applicationCache, go here : http://www.html5rocks.com/en/tutorials/appcache/beginner/
it's under the "Updating the Cache" section.
Gurus of SO
I am trying to play with CACHE MANIFEST/HTML5. My app is JS heavy and built on jquery/jquerymobile.
This is an excerpt of what my Manifest looks like
CACHE MANIFEST
FALLBACK:
/
NETWORK:
*
CACHE:
/css/style.css
/js/jquery.js
But somehow, the app doesn't load the files the first time itself and the entire app breaks down.
Is my format wrong?
Should I never load JS into the Cache?
How should I treat this differently to always check the network first if anything isn't available and only load stuff available from the Cache?
Thank you.
I tried a simple page with your cache manifest and it worked fine for me, so I'm not really sure what the problem is. But,
Yes, there is something wrong with the format. The entries in the FALLBACK section need to have two parts: a pattern, and a URL. This says "if any page matching the pattern is not available offline, display the URL instead (which will be cached)." The main example of this (as shown here) is "/ /offline.html", which means "for all pages, if we are offline and they are not cached, display /offline.html instead." However, I don't think this is the source of your problem since I tested it with your exact manifest and it still worked.
There is nothing special about JS files. It should be fine to load them into the cache.
I don't understand the third question. There are possibly two goals here: a) how do you check to see if there is a newer version of the file available online first, before going back to the cache, and b) how do you check the network to see if there is a file that is not cached, and if we are offline, fall back to an error page. The answer to (a) is that once you have turned on the cache manifest, things work very differently. It will never check for new versions of the files unless there is a new version of the manifest also. So you must always update the manifest whenever you change any files. The answer to (b) is the FALLBACK section.
See Dive Into HTML5's excellent chapter on this, particularly the section "The fine art of debugging, a.k.a. “Kill me! Kill me now!”" which explains how the manifest updates.
Also I don't think we've gotten to the meat of your question, because it's unclear what you mean by "the app doesn't load the files the first time itself". Which files don't load? Do they load properly after a refresh? Etc.
The only way I got this to work to refresh a cache was to rename the manifest file with a commit number or timestamp, and change the cache declaration to
<html manifest='mymanifest382330.manifest'>
I made this part of my build.