When setting the prefer-online setting I expect the browser to request the page at every refresh of the browser, but it is not the case.
Here is my manifest :
CACHE MANIFEST
SETTINGS:
prefer-online
NETWORK:
*
Yet when I refresh the browser it only requests the manifest to the server. It only requests the page when I update the manifest ...
And there is no headers (expires or max-age) set on the page.
(tested on chrome & firefox)
NB: When updating the manifest, the browser re downloads the assets, but still displays the old version ... It is only on the next load that the browser uses the new assets. Why ?
I don't see what the AppCache manifest is for, since you want to bypass the cache and just use the network. Keep in mind that the regular caching might still apply, regardless of the AppCache manifest, so check the Expires, Last-Modified and similar headers.
As for your question:
NB: When updating the manifest, the browser re downloads the assets, but still displays the old version ... It is only on the next load that the browser uses the new assets. Why ?
This is because the user agent will immediately use the latest cached version of your assets, then start checking the linked resources listed in the manifest for updates. When the user agent detects that the manifest has changed, and thus it has to check for updates, it will fire a checking event.
When the update checking process has finished (and it might take a long time, if you have lots of resources) it will fire an updateready event. Only the resources fetched after this event will be the fresh new ones (that's why it's usually adviceable to use window.applicationCache.swapCache() to tell the browser to swap the old cache for the new for the next page load, or simply reload the page and be done with it).
You will find more detailed explanations about these topics here: http://www.html5rocks.com/en/tutorials/appcache/beginner/
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 have a versioned cache manifest:
#version = e5b4271
Every time this version changes, my webapp loads the new manifest, but it never loads update files from the server. Even when I clear the browser cache (not the application cache itself), or hit Ctrl+Shift+R to force it to fetch a new version, it still loads the files from the old appcache.
The only way I can get it to update is to clear the browser's application cache in settings, but obviously this is unacceptable because I need it to update for regular users.
Any ideas why this would happen?
Just figured it out. I'm using Flask's development server, and it seems by default (via werkzeug) it sends cache headers for 12 hours for static files. Adding the following to my flask config solved this:
SEND_FILE_MAX_AGE_DEFAULT = -1
If anyone else has this issue, check your server config to make sure cache headers are not sent with static files. You can check this in the network tab in chrome during the first load of the file.
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.
I have a special kiosk-solution with chrome where I need chrome to upon application start, load the start-url from cache, not try to fetch it online.
The reason is that this is, like I said, a kiosk-mode presentation, is is a screen standing in the public that reboots every night, and if the reboot happens while the ISP has downtime on the internet connection, chrome will only show an error page.
If I can get it to load the cached version of the page though, instead of trying to fetch it online, then the last valid version of the page will show, and through some nifty ajax-workings of mine ;) it will automatically update after a while. If THAT update fails, the currently displayed version of the page will remain until a subsequent update succeeds.
See my problem?
In a browser like firefox I could do it by starting the browser in off-line mode and after page load switch it to online-mode. Only FF doesn't work for me in the particulat project, and Chrome doesn't seem to have an off-line mode?
You could use HTML5 Offline Web Applications to accomplish that. It's probably very easy to set up in your case, just add a file like the following to your app's directory:
CACHE MANIFEST
index.html
help.html
style/default.css
images/logo.png
images/backgound.png
NETWORK:
server.cgi
This manifest should contain all the files you'll need to display some useful information and later grab current content via AJAX. There's also a NETWORK section, where you have to specify things that should not be cached (ie the script that delivers your Updates via AJAX).
You can load the manifest file by adding a manifest attribute to your tag (cache-manifest is the name of the file above):
<html manifest="cache-manifest">
Make sure your server delivers the cache manifest with a MIME-type of
text/cache-manifest MIME
Type or copy-paste the below flag setting into the chrome address bar.
chrome://flags/#enable-offline-mode
scroll down to enable offline stale mode.
Restart your browser.
If an offline version of the page is available in the system cache it will load up when you are not connected.
Every URL can be linked to a single cache manifest. But I want several cache manifests linked to a same URL. Here is the reason:
Some files I want to be cached are rarely updated and large.
So everytime the cache gets updated these large files get re-downloaded even though they may not have been changed.
So I want to split up the cache. One cache for theses rarely updated large files and another cache for the often updated light files.
Do you guys have any idea how to split up an HTML5 cache?
The most efficient way is:
a) Use far-future expiration date (max-age) on all resources mentioned in manifest's CACHE section and add timestamp suffix to each file in the CACHE section, e.g.:
CACHE:
menu_1355817388000.js
toolbar_1355817389100.js
b) When any of the above files change on the server, regen/update manifest to change the timestamp. Only the file with the modified timestamp will get downloaded next time. Mission accomplished.
Note: Reload the page twice in the browser, as on the first refresh browser downloads just the manifest and uses old cached resources to paint the page. This is done to speed up displaying the page (there are tricks to handle this issue of double refresh, but they are outside the scope of your question)
See more info in this long but best article I ever seen on appcache.
Use an iframe
Your page's cache manifest would include the light files and the cache manifest of an iframe loaded by this page would include the large files
On chrome the iframe's application cache will also be used for the page. I didn't tested this method on other browsers yet.
see a live example at http://www.timer-tab.com and if you are using chrome see its split up cache at chrome://appcache-internals/
When the manifest file is changed and the files of the application cache are downloaded again, the normal HTTP caching rules still apply. This means that if you set the correct HTTP caching headers for these large files, you'll get a 304 so these files are not downloaded again. So it's not necessary to split the application cache.
Maybe an answer but I'd more like to shed some light on my findings as a I troubleshoot my own webapp.
I've discovered that I can use 2 iframes (manifest_framework) and (manifest_media) to load the manifests, but i'm still not exactly clear how they are targetted, but I had limited success.
manifest_framework:
CACHE MANIFEST
CACHE:
appdata.ini
dialog.png
jquery.min.js
login.htm
login.js
manifest.appcache.js
NETWORK:
*
FALLBACK:
manifest_media:
CACHE MANIFEST
CACHE:
manifest_fwk.php
od/audio_track_1_1.m4a
od/audio_track_1_2.m4a
od/audio_track_1_3.m4a
od/audio_track_1_4.m4a
od/video_1.mp4
od/video_2.mp4
od/video_3.mp4
NETWORK:
*
FALLBACK:
./ webapp.php
./index.php is the page the 'landing page' which itself isn't cached but falls back to webapp.php when offline.
What I don't understand is how these link to the webapp.php page.
I am finding I can only get access to one or the other manifests cache.
The above works in mobile safari, the media would be cached, and image but not necessarily the JS or images in the framework manifest.
Anyone have more examples where multiple manifests are referenced from the one URL/page?
The W3C working group has abandoned the file system api, so it SHOULD NOT BE USED anymore.
We'll likely see it fall off the next version of Chrome.
http://www.w3.org/TR/file-system-api/
CACHE MANIFEST
# This is a comment.
# Cache manifest version 0.0.1
# If you change the version number in this comment,
# the cache manifest is no longer byte-for-byte
# identical.
demoimages/mypic.jpg
demoimages/yourpic.jpg
demoimages/ourpic.jpg
sr/scroll.js
NETWORK:
# All URLs that start with the following lines
# are whitelisted.
# whitelisted items are needed to help the site function, you could put regularly
# changing items here
http://example.com/examplepath/
http://www.example.org/otherexamplepath/
CACHE:
# Additional items to cache.
demoimages/allpics.jpg
FALLBACK:
demoimages/currentImg.jpg images/stockImage.jpg`
If the Iframe trick does not work, use the HTML5 FileSystem API
See http://updates.html5rocks.com/2012/04/Taking-an-Entire-Page-Offline-using-the-HTML5-FileSystem-API