Possible to bypass service worker for video sources?

[supermoos]

trafficstars

First, thank you for this great library!

I have a use case where I want to both be able to bypass the service worker cache and also for some videos cache them. Right now I am just setting a

[sw-toolbox] Strategy: network only [http://domain.com/video/53ff58afaf3f1ca111126715.mov]

Fetch API cannot load http://domain.com/video/53ff271c1cd2ce4082931973.mov. Request header field range is not allowed by Access-Control-Allow-Headers in preflight response.

The FetchEvent for "http://domain.com/video/53ff271c1cd2ce4082931973.mov" resulted in a network error response: the promise was rejected.
(program):1 Uncaught (in promise) TypeError: Failed to fetch(…)

Is there a way to to let certain videos bypass the service worker cache based on say an url-pattern, and let others get cached?

[jeffposnick]

There is what looks to me like a bug in Chrome that prevents a service worker's fetch handler from properly handling a request originating from <video> when the src lives on a domain that doesn't support CORS.

I don't know that there's anything that can be done at the sw-toolbox level to support unless that bug is resolved or someone posts a workaround.

Do things work as expected if you access a video that's served from the same domain as your page?

[wibblymat]

Would it work if the request was rewritten to be {mode: 'no-cors'} in the handler?

[jeffposnick]

Based on my experience with a standalone repro (linked to from the Chrome bug report), that wouldn't help.

You can rewrite the request to be {mode: 'no-cors'}, but since the controlled page doesn't expect an opaque response, the page won't use it to populate the <video> tag.

[gauntface]

If you don't call event.respondWith - this should act as the browser normally would without a service worker.

To make use of this in swtoolbox I imagine you would need some notion of a 'shouldInterceptRequest' that could be called before any routing is performed.