An application cache is a set of cached resources consisting of:
Master entries
These are documents that were added to the cache because a browsing context was navigated to that document and the document indicated that this was its cache, using the manifest attribute.
Explicit entries
These are the resources that were listed in the cache's manifest in an
explicit section (CACHE).
Fallback entries
These are the resources that were listed in the cache's manifest in a fallback section.
The resource that declares the manifest (with the manifest attribute) will always get taken from the cache, whether it is listed in the cache or not, even if it is listed in an online whitelist namespace.
This means that your HTML that includes the manifest file will be always a master entry which is cached and accessed from the cache even the client is online.
Let's face it, this is a pain in the neck in same cases.
There is a simple workaround
1. create an OTHER HTML that will include the manifest file
2. from the ORIGINAL HTML remove the manifest include and create an iframe that includes the OTHER HTML
In this case the master entry will be this OTHER HTML, which does not affect whitelisting the ORIGINAL HTML.
I'd like to emphases that this is just a workaround and i'd like to have a better solution.
You can also follow the related whatwg discussion.
Hey, it was nice catching up with you yesterday. Here's the note from the reference [1] related to offline manifests:
ReplyDelete> Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly mentioned.
> With the exception of "no-store" directive, HTTP cache headers and restrictions on caching pages served over TLS (encrypted, using https:) are overridden by manifests. Thus, pages will not expire from an application cache before the user agent has updated it, and even applications served over TLS can be made to work offline.
Not sure if Cache-Control: no-store solves your particular problem and if UA's really honor it IRL, but might be worth a shot. :)
Zaki
[1] http://www.whatwg.org/specs/web-apps/current-work/#offline section 6.6.1
thx Zaki! unfortunately HTTPS is not an option for us.
ReplyDeleteThis does not seem to work (tested in Chrome). The files used in ORIGINAL HTML that are listed in the manifest file are not loaded from the cache. Instead they are downloaded like usual.
ReplyDeleteDoes anything else need to be in the OTHER HTML besides the html tag referencing the manifest file?
Does it matter where the iframe is added to the ORIGINAL HTML? I tried the begging and the end of the body.
Hi.
ReplyDeleteIm working with appcache, and this issue is really annoying.
I posted in my blog the researches about this.
Actually, Google Chrome seems to be ignoring Cache-Control:no-store.
http://jaydson.org/en/html5-appcache-cache-control-no-store
Well, this workaround using Iframes seems to be a simple solution, but sure, the spec needs to be upgraded to fix that.
Tks.
Hi,
ReplyDeleteI have been experiencing exactly this same problem with iOS. I found that adding "Cache-control: no-store" to the page that declares the manifest stops the entire manifest from working!; so nothing gets cached. I am loathe to use the iframe workaround because it really seems like a bodge-fix.
I guess the Iframe-workaround doesn't work. If you think the files are loaeded from appcache: no. they're coming from browser cache.
ReplyDeletedisable browsercache in devtools-settings und look at "network". you can see, that all elements will be loaded via network and don't come frome (app)cache.
The high speed laser trimming supplier can be used for precise manufacturing.
ReplyDelete