The Cache objects do not expire unless authors *or users* delete the entries.

[bsittler]

https://w3c.github.io/ServiceWorker/#cache-lifetimes says:

The Cache objects do not expire unless authors delete the entries.

I propose to extend this to allow the possibility of the user deleting caches and individual cache entries. While I don't think this is likely to be common, it does mean the cache storage mechanism has weaker overall consistency guarantees than are otherwise implied:

The Cache objects do not expire unless authors or users delete the entries.

This might be understood to mean that developers can rely on end-users not being able to modify cache contents — at least, not without running code using the developer tools or an equivalent mechanism. However, at least in Chrome, caches can also be manually removed by the user (for instance, to reduce exposure to privacy risks or to reclaim storage space) without necessarily stopping the origin's Service Workers or removing the origin's Service Workers or other storage.

For instance, using:

Settings > Advanced > Privacy & Security > Content settings > Cookies > See all cookies and site data > [hostname] > Cache Storage > X

... the user can remove all caches for an origin. Those caches are also removable using the developer tools, but given the intended audience I think it's less clear that that disagrees with the wording of the spec. That part is in:

Developer Tools > Application > Clear storage > [uncheck all but "Cache storage"], Clear site data

The developer tools also allow an individual cache or cache entry to be selected and deleted using the "Cache" tree in the side-navigation area.

+@inexorabletash

[bsittler]

Note that the separate possibility for user agent clearing of caches after author opt-in is already proposed in the semi-related #863 - however I don't think there is any dependency relationship between the two proposals as the actor is distinct, and for a user agent acting on the user's behalf in the course of carrying out the user's specific instruction to delete caches or cache entries I don't think requiring opt-in is reasonable

edit: this came up while discussing more immediately effective UI-initiated cache deletion in cases where outstanding cache handles remain open in still-running scripts https://crbug.com/795701#c30

[jakearchibald]

This seems a little nit-picky. When you use developer tools, isn't it assumed you're operating at a privilege greater than the author? Eg, if CSP has blocked eval, the devtools console still works.

[mfalken]

Doesn't the browser also delete the Cache if it needs to free up storage space?

[jakearchibald]

@mattto the cache API is part of origin storage. The browser may purge origin storage, but it shouldn't delete individual caches or cache items any more than it should remove entries/stores from indexeddb.

[Ryandev]

Is there a use case for supporting the Expires or Cache-Control headers or setting expiration against the CacheStorage API

Our use-case is currently PWA Audio tours which can contain >1gb of cache controlled content & if the user leaves the page without requesting the PWA to delete any content, then according to the spec that space persists & the browser will not remove this.

Having some eviction criteria against the CacheStorage would allow the browser to remove Cache Responses in the absence of the service-worker

[inexorabletash]

Having eviction priorities and/or expiration policies has been discussed as a potential feature of storage buckets, which would extend this beyond the Cache API.