As a consequence I believe sw-precache had an elaborate way of avoiding http cache coherence problems by creating new Cache objects for each entry as a cache busting mechanism.
-
-
Replying to @wanderview @AdamRackis and
Anyway, I'm not trying to be critical of chrome here... more just hoping
@jeffposnick and@gauntface are able to remove that cache busting workaround now.1 reply 0 retweets 1 like -
Replying to @wanderview @AdamRackis and
Both
@workboxjs and sw-precache let developers skip cache-busting for resources that already include versioning in their URLs. In@workboxjs for assets that don't have versioned URLs, we track asset versions out-of-band via IDB, and keep the original URLs in Cache Storage.1 reply 0 retweets 1 like -
Replying to @jeffposnick @AdamRackis and
Is that necessary even with `cache.add(new Request(url, { cache: 'no-cache' })`, though?
1 reply 0 retweets 1 like -
Replying to @wanderview @AdamRackis and
Keeping hashes of the file contents around somewhere is necessary so that we can to refresh unversioned URLs like `index.html` iff something changed. When we actually make our network requests, we use the cache control options when available: https://github.com/GoogleChrome/workbox/blob/v3/packages/workbox-precaching/models/PrecacheEntry.mjs#L54 …
2 replies 0 retweets 2 likes -
Replying to @jeffposnick @AdamRackis and
What does it mean to "refresh unversioned URLS iff something changed"? It seems you must have already loaded it again to determine if something changed? Are you just avoiding the cache.put()?
1 reply 0 retweets 0 likes -
Replying to @wanderview @AdamRackis and
In
@workboxjs, for URLs like /index.html that don't include hashes, we compare a hash that's included in the sw.js file with a hash that we store locally using IDB, and only fetch + cache.put() a given URL if the hashes differ.2 replies 0 retweets 2 likes -
Replying to @jeffposnick @AdamRackis and
Would exposing the SRI hash as `Response.integrity` help you avoid the IDB code? I guess it would have to be async to handle incomplete body, but in Cache API case it could be ready immediately.
1 reply 0 retweets 0 likes -
Replying to @wanderview @AdamRackis and
If Response.integrity were always set to something meaningful, I guess it could avoid some IDB code? Would using the Cache Storage API for looking that up necessarily be a win vs. using IDB? (What we're doing might be closer to the ETag model than to Response.integrity?)
1 reply 0 retweets 1 like -
Replying to @jeffposnick @AdamRackis and
Having an extra field in Cache API would be marginally better if it meant you didn't need IDB at all. We've talked about exposing a hash for the body before and we store it for the Request.integrity now. It was just a thought.
1 reply 0 retweets 1 like
I've often thought that we should perhaps allow more arbitrary metadata in Cache entries.
-
-
Replying to @slightlylate @jeffposnick and
Well, its easier to add something like a hash which is close to an existing concept like integrity/etag. General purpose metadata might be a tougher sell. I dunno, though, call it "extra headers" or something.
1 reply 0 retweets 0 likes -
Replying to @wanderview @slightlylate and
We're also using IDB for cache expiration metadata, and for serializing failed requests + metadata for background sync retries. In the cache expiration case, we use indices and custom sorting, which is squarely in IDB's wheelhouse. So I doubt we'd drop IDB.
1 reply 0 retweets 2 likes - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.