Created attachment 164622 [details] Local resource caching test 1) extract the attached archive 2) open local-cache.html in a tab (and do not close it): it should be displaying img1.png 3) copy img2.png -> img1.png 4) reload the tab: it's still showing img1.png double CachedResource::freshnessLifetime() const { // Cache non-http resources liberally if (!m_response.url().protocolIsInHTTPFamily()) return std::numeric_limits<double>::max(); Based on this ^^^, one could argue that the above behavior is deliberate. But it's not consistent with how statically declared resources are handled: if inline styling is used instead of JS in the test above, reloading the tab refreshes the image as expected. I tracked this down to CachedResourceLoader::determineRevalidationPolicy(): // Check if the cache headers requires us to revalidate (cache expiration for example). if (existingResource->mustRevalidateDueToCacheHeaders(cachePolicy())) { ... return Reload; } return Use; While the page is loading, cachePolicy() returns CachePolicyRevalidate and the branch is taken, forcing a reload. After the frame loader is finished, the cache policy is CachePolicyVerify due to FrameLoader::subresourceCachePolicy(): if (m_isComplete) return CachePolicyVerify; Since local resources never expire, the branch is not taken anymore and the cached resource is used. I'm not familiar with the caching infrastructure, so it's unclear to me how/whether the behavior in these two cases can be aligned without making local resources effectively uncacheable. Maybe purging non-http resources on reload could be a compromise?
What is the actual problem you are having? That dynamically loaded local resources fail to update on reload?
(In reply to comment #1) > What is the actual problem you are having? That dynamically loaded local resources fail to update on reload? That's the original Chromium bug report, yes: http://code.google.com/p/chromium/issues/detail?id=46494 But, personally, I find the inconsistency in behavior for statically loaded local resources vs. dynamically loaded local resources to be the real issue (in the sense that I could buy the argument that in the absence of any hints and specialized validators we are caching local resources indefinitely, as long as the reload behavior is consistent).
That inconsistency exists for remote resources too, and is a multi-faceted issue. See bug 30862.
(In reply to comment #3) > That inconsistency exists for remote resources too, and is a multi-faceted issue. See bug 30862. I see - then it makes sense to mark this as a dupe. *** This bug has been marked as a duplicate of bug 30862 ***