> GOTCHA #3: THE APPLICATIONCACHE IS AN ADDITIONAL CACHE, NOT AT ALTERNATIVE ONE<p>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.<p>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.<p>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.<p>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).<p><pre><code> PassRefPtr<ResourceHandle> ApplicationCacheGroup::createResourceHandle(const KURL& url, ApplicationCacheResource* newestCachedResource)
{
ResourceRequest request(url);
m_frame->loader()->applyUserAgent(request);
request.setHTTPHeaderField("Cache-Control", "max-age=0");</code></pre>