Bug 97596
| Summary: | ApplicationCache and WebCore::MemoryCache don't always play well together. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Nordman <michaeln> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, beidson, koivisto, michaeln |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Michael Nordman
ApplicationCache and WebCore::MemoryCache don't always play well together. There's at least one way in which this can do the wrong thing.
A document associated with an appcache can mistakenly load resources contained in the memcache instead of loading the particular version pinned in the appcache. This breaks its guarantee of loading the particular version of the resource at the time the associated cache was updated.
I think the reciprocal could happen too, where an appcache response is loaded into the memcache. And that response is then used to satisfy a request to load a resource into a document that is not associated with the appcache. That unassociated document could be loading stale data.
Using only the <url> as the key is problematic given how appcache'ing is supposed to work, where which resource to load is dependent on which document is doing the loading.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Do you have a test case for this? I'm not sure what code path you have in mind - we just load from application cache without consulting other loader machinery.
Michael Nordman
The pages referenced in this email thread demonstrate the problem.
I was looking at CachedResourceLoader, methods like requestCSSStyleSheet and requestResource). Looks like that class sits in on top of ResourceLoader which is where the appcache gets consulted. If the CachedResourceLoader finds something in the memory cache for <url>... it doesn't get as far as ResourceLoader.
Michael Nordman
oh... i forgot the link to the discussion in comment #2
http://lists.w3.org/Archives/Public/public-fixing-appcache/2012Sep/0028.html
Alexey Proskuryakov
Indeed, we should be checking with appcache before checking memory cache (and then appcache needs to become smarter, keeping pre-parsed stylesheets etc.)
Michael Nordman
(In reply to comment #4)
> Indeed, we should be checking with appcache before checking memory cache (and then appcache needs to become smarter, keeping pre-parsed stylesheets etc.)
Having the appcache replicate the logic of the memcache worries me. Alternatively, the appcache could remain dumb if the memcached uses a different 'key' to identify resources. If the key were <url,appcacheid> instead of just <url>, i think resources could be loaded out of the appcache and then deposited in the memcache and available for quick access just like resources loaded from the network or the httpcache are.