661115 - Cache-requests with policy STORE_ON_DISK_AS_FILE is always reloaded from server

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect)

Description

[Bjarne (:bjarne)]

This comes from bug #654926, comment #32.

If we request a resource with policy STORE_ON_DISK_AS_FILE the cache will not even be searched for the entry but always reloaded from the server. Moreover, the cache would have duplicate entries of the resource.

We probably would like to handle this better, as well as the subtle case identified in bug #654926, comment #29 where a cache-entry might be re-used while pending deactivation. The latter seems to occur rarely so we might consider to never re-use entries like this if it turns out to complicate things.

Comment 1

[Bjarne (:bjarne)]

This is a little more subtle than first assumed if we limit scope to nsHttpChannel as the client to the cache:

nsHttpChannel does not allow setting policy STORE_ON_DISK_AS_FILE (via nsHttpChannel::SetCacheAsFile()) before its cache-entry is available. In other words: When searching the cache, this flag is never set. (Also, according to nsICachingChannel.idl, setting this flag typically happens from OnStartRequest, i.e. after cache-entry is found.)

This means that the issue described in comment #0 (when limiting scope to nsHttpChannel) is wrong: The cache will indeed be searched, but it may find a cached entry with or without policy STORE_ON_DISK_AS_FILE.

The remaining issue is when a request with policy STORE_ON_DISK_AS_FILE re-uses a cached entry without this policy: In this case the attribute nsICachingChannel::cacheFile will be unavailable (and throws if you access it) and the policy set on the request has been violated. This, IMO, must be fixed.

Comment 2

[Bjarne (:bjarne)]

Attachment: Test demostrating the problem

Shows effect of reusing a cached entry without policy STORE_ON_DISK_AS_FILE

Comment 3

[Michal Novotny [:michal]]

old cache bug