In my previous post on HTML5's Cache Manifest, Ray Camden and I got into a great discussion about how pages would interact with resources cached by the Cache Manifest file. I was explaining to him that in my experience, any file that linked to the cache manifest was itself automatically cached even if it (the calling page) was not explicitly defined as a line item within the cache manifest. This begged the question: can non-cached pages take advantage of resources otherwise available in the application cache?
Answering this question was not easy at all and took a lot of jumping back and forth between standard and offline work mode in FireFox. After a bunch of playing around, toggling between modes, and clearing caches, I have come to the conclusion that, at least in FireFox, non-cached pages cannot access resources stored offline within the application cache. To see this in action, take a look at the following video:
I know I was jumping around in that video quite quickly, so I'm going to reproduce the code below. I won't go into too much detail here as to what it's all doing as this was more about a functional test than an explanation. That said, here is the main test page - notice that it is a standard HTML page that makes no reference to any offline cache manifest.
Because the above page was not cached in any way, I did need to create a page that referenced the cache manifest and therefore created the offline application cache. This page was the second tab I had opened in my FireFox demo:
<!--- Use the HTML5 doc type and provide a link to the Cache Manifest file for this application. ---> <!DOCTYPE HTML> <html manifest="./cache_manifest.cfm"> <head> <title>I Am The Cacher!</title> </head> <body> <h1> I Am The Cacher! </h1> <p> All I do is define a link to the cache manifest that will server to cache the image assets of the application. </p> <cfoutput> <p> Now: #timeFormat( now(), "hh:mm:ss TT" )# </p> </cfoutput> </body> </html>
As you can see in the above markup, this page makes use of the HTML5 doctype and the cache manifest. The cache manifest that it linked to is defined here:
<!--- Define the Cache Manifest content. I'm doing it this way since the "CACHE MANIFEST" line needs to be the first line in the file and storing it in a buffer allows us to TRIM later without having ugly line breaks. ---> <cfsavecontent variable="cacheManifest"> <!--- NOTE: Cache Manifest must be the very first thing in this manifest file. ---> CACHE MANIFEST <!--- When a cache manifest is reviewed by the browser, it uses a complete byte-wise comparison. As such, we can use COMMENTS to defunk a previously used cache manifest. In this way, we can use a version-comment to indicate change even when the file list has not changed. NOTE: If ANY part of this file is different from the previous cache manifest, ALL of the files are re-downloaded. ---> # Cache Manifest Version: 1.8 # Images that get viewed. ./images/1.jpg ./images/2.jpg ./images/3.jpg ./images/4.jpg ./images/5.jpg </cfsavecontent> <!--- ----------------------------------------------------- ---> <!--- ----------------------------------------------------- ---> <!--- Let's reset the output and set the appropriate content type. It is critical that the manifest file be served up as a type "text/cache-manifest" mime-type. NOTE: We need to be careful about the whitespace here since the very first line of the file must contain the phrase, "CACHE MANIFEST". As such, we must TRIM() the content. ---> <cfcontent type="text/cache-manifest" variable="#toBinary( toBase64( trim( cacheManifest ) ) )#" />
As you can see, the cache manifest is only caching the 5 images. So, unless I am missing something critical here in this exploration, what I am seeing is that non-cached pages are not able to access resources cached in the offline application cache by the cache manifest.
Want to use code from this post? Check out the license.