> GOTCHA #3: THE APPLICATIONCACHE IS AN ADDITIONAL CACHE, NOT AT ALTERNATIVE ONE
This section is not quite true, at least for WebKit. This article states that the application cache will use the normal browser cache when making outgoing requests, honoring whatever cache control headers were sent by the server. What actually happens is that the browser always forces a revalidation of the content with the server, regardless of what the cache control headers that had been served.
Now, I certainly /wish/ it were the case that it honored the normal browser cache, but it simply doesn't. The result is that the application cache makes these outgoing requests painfully and arduously one-at-a-time, waiting for the previous one to entirely complete before making the next one... over a mobile data connection this takes /forever/, and it is quite possible that it simply does not finish by the time the process is aborted by one of these needless server requests failing or the window being closed.
Normally, you can mitigate these issues by sending files with "cache this effectively forever" headers and always using unique filenames, but with the application cache manifest system (which you are going to be using to support guaranteed-consisten offline operation) you are forced to wait for every request to resubmit before seeing the update.
Here is the code from WebKit's ApplicationCacheGroup.cpp, where you can see "max-age=0" being sent as Cache-Control for the outgoing requests. (Sending that header as a user-agent serves to "force any intermediate caches to validate their copies directly with the origin server", per RFC2616).
I don't think this is the case, not in Chrome anyway.
See http://www.youtube.com/watch?v=q7QL0NAwES8 - All files are "must-revalidate" except the JS file which is far-future cached. When the manifest is changed an update is triggered, all files are updated except the JS file, which is assumed to be fresh because of the far future expiry.
You see similar behaviour when no caching headers are served, heuristics take over & files may be updated from the normal browser cache rather than going to the server.
I will then be much more specific and say "MobileSafari". My mobile application is part of an iOS application, so I only use and care about MobileSafari as a target. I definitely am quite careful with my Cache-Control headers, and am documenting this not just with logs but with WebKit code.
(edit/clarification: While I get this code from the WebKit repository, I forgot that the specific area of WebKit I'm looking at is WebCore, so I should really be calling it WebCore and not WebKit, considering they are separate libraries and quite separate projects on some platforms.)
Someone else I know (who may or may not decide to actually chime in) saw this interaction and decided to do some tests with various browsers, stating that 1) Safari worked as I said, 2) Firefox refetched the request but did not set the Cache-Control header, and 3) Chrome worked as you say.
Confirmed! Interesting. Safari on OSX and iOS makes the request regardless. Firefox didn't request the far-future file, but also didn't request one of the must-revalidate files. Not sure what it's doing. Good spot.
This section is not quite true, at least for WebKit. This article states that the application cache will use the normal browser cache when making outgoing requests, honoring whatever cache control headers were sent by the server. What actually happens is that the browser always forces a revalidation of the content with the server, regardless of what the cache control headers that had been served.
Now, I certainly /wish/ it were the case that it honored the normal browser cache, but it simply doesn't. The result is that the application cache makes these outgoing requests painfully and arduously one-at-a-time, waiting for the previous one to entirely complete before making the next one... over a mobile data connection this takes /forever/, and it is quite possible that it simply does not finish by the time the process is aborted by one of these needless server requests failing or the window being closed.
Normally, you can mitigate these issues by sending files with "cache this effectively forever" headers and always using unique filenames, but with the application cache manifest system (which you are going to be using to support guaranteed-consisten offline operation) you are forced to wait for every request to resubmit before seeing the update.
Here is the code from WebKit's ApplicationCacheGroup.cpp, where you can see "max-age=0" being sent as Cache-Control for the outgoing requests. (Sending that header as a user-agent serves to "force any intermediate caches to validate their copies directly with the origin server", per RFC2616).