I have created a PWA test project to find out how to get audio caching working with Workbox, including scrub/seek using the range requests plugin.
I want the app to precache all audio and for this audio to be playable offline, including scrub/seek.
Pre-caching the audio can be done in one of two ways:
cache.add(URL)But audio files cached with the first method (injectManifest) will not scrub/seek because the Workbox pre-cache does not support range request headers. So you need to put a range request enabled router in front of the pre-cache for audio files if you want to be able to scrub through/seek within a cached audio file.
Pre-cached audio with a range requests enabled router will play and scrub/seek fine in Chrome and Firefox when app is served from localhost but fails to play in Chrome when served from Firebase.
I see the same error for all audio files that are pre-cached with a range requests router in front of them:
Router is responding to: /media/audio/auto-pre-cached.mp3
Using CacheOnly to respond to '/media/audio/auto-pre-cached.mp3'
No response found in the 'act-auto-pre-cache-wbv4.3.1-actv0.0.1' cache.
The FetchEvent for "https://daffinm-test.firebaseapp.com/media/audio/auto-pre-cached.mp3" resulted in a network error response: the promise was rejected.
CacheOnly.mjs:115 Uncaught (in promise) no-response: The strategy could not generate a response for 'https://daffinm-test.firebaseapp.com/media/audio/auto-pre-cached.mp3'.
at CacheOnly.makeRequest (https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-strategies.dev.js:343:15)
Chrome versions tried:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
The files are present in the Workbox caches. The only difference I can see between locahost and Firebase is in the cached response headers:
Localhost
cache-control: max-age=3600
content-length: 3770956
content-type: audio/mpeg; charset=utf-8
Date: Mon, 07 Oct 2019 09:37:03 GMT
etag: "12456134-3770956-"2019-09-29T20:05:00.314Z""
last-modified: Sun, 29 Sep 2019 20:05:00 GMT
server: ecstatic-2.2.2
Firebase
accept-ranges: bytes
cache-control: max-age=3600
content-encoding: gzip
content-length: 3686565
content-type: audio/mpeg
date: Mon, 07 Oct 2019 11:47:43 GMT
etag: 267d9ec42517198c01e2cad893f1b14662a2d91904bc517aeda244c30358457c
last-modified: Mon, 07 Oct 2019 03:48:25 PDT
status: 200
strict-transport-security: max-age=31556926; includeSubDomains; preload
vary: x-fh-requested-host, accept-encoding
x-cache: MISS
x-cache-hits: 0
x-served-by: cache-lhr7363-LHR
x-timer: S1570448862.315027,VS0,VE1472
Firefox works fine in both cases.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
You can find the code for the test app here including a full description of the test setup, expectations and results:
https://github.com/daffinm/audio-cache-test
And the app is currently deployed on Firebase here if you want to take a look:
https://daffinm-test.firebaseapp.com/
Does anyone have any idea what's going on here and why the pre-cached audio with range request routers are failing to play in Chrome? Is this a Chrome bug and/or a Workbox mis-configuration and/or a Firebase configuration issue - or something completely different? (I have contacted Firebase support and they are being very helpful but are currently unable to enlighten me).
The presence of the Vary header in the Firebase responses sounds like the culprit. By default, the Cache Storage API will use the Vary header when determining whether or not there's a cache match. You can override this default behavior by passing in {ignoreVary: true} when querying the Cache Storage API. Workbox supports this as an option you can provide when creating your strategy, via the matchOptions parameter.
It looks like you're already passing in ignoreSearch: true, so you can just add ignoreVary: true alongside that.