- From: Andrew Sutherland <notifications@github.com>
- Date: Fri, 31 Jul 2026 14:30:36 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/pull/1764/c5147634050@github.com>
asutherland left a comment (w3c/ServiceWorker#1764) This seems like a good change; we always wanted this capability. I do like that this provides UAs the ability to potentially bias towards always going to cache based on user preference but also having the latitude to use the network for latency reasons. One question I think this capability inherently raises is "If we are fetching something from the network and it's not in the cache, does it get put in the cache? Or can the cache entry be updated with the network result?". The current answer is "no" and the existing [understanding cache lifetimes](https://w3c.github.io/ServiceWorker/#cache-lifetimes) prose already incidentally answers the question, but it could be nice to add some non-normative text around [InstallEvent](https://w3c.github.io/ServiceWorker/#installevent-interface) to maybe reiterate that point. Refreshing my memory from https://github.com/WICG/service-worker-static-routing-api/blob/main/final-form.md I do see that there is an updatedCacheName mechanism for stale-while-revalidate and it does seem desirable that any cache updating would be quite explicit in that way. But since we also don't really have any automatic eviction mechanism, leaving it to the SW itself to perform any content updates does seem appropriate rather than risking making it easy to create an ever-growing cache. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/pull/1764#issuecomment-5147634050 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/pull/1764/c5147634050@github.com>
Received on Friday, 31 July 2026 21:30:40 UTC