Bug 97044

Summary: Inconsistent caching of local resources
Product: WebKit Reporter: Florin Malita <fmalita>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ap, beidson, koivisto
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Local resource caching test none

Description Florin Malita 2012-09-18 14:22:51 PDT
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?
Comment 1 Antti Koivisto 2012-09-19 13:43:07 PDT
What is the actual problem you are having? That dynamically loaded local resources fail to update on reload?
Comment 2 Florin Malita 2012-09-19 14:26:11 PDT
(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).
Comment 3 Alexey Proskuryakov 2012-09-19 14:39:23 PDT
That inconsistency exists for remote resources too, and is a multi-faceted issue. See bug 30862.
Comment 4 Florin Malita 2012-09-19 15:12:51 PDT
(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 ***