search

gatsbyjs / gatsby

The best React-based framework with performance, scalability and security built in.
https://www.gatsbyjs.com
MIT License
55.28k stars 10.31k forks source link

Media players and Gatsby #2 #10035

Closed johnelliott closed 5 years ago

johnelliott commented 5 years ago

Summary

My first issue šŸ˜„

Add media file regex to plugin-offline workbox navigateFallbackBlacklist list.

Basic example

        navigateFallbackBlacklist: [
          /\?(.+&)?no-cache=1$/,
          /\.(mp3|mp4|m4a)(\?.*)?$/
        ]

Motivation

I was experiencing some audio player slowness and saw that the service worker appeared to be intercepting requests for my mp3 files from an HTML5 audio tag. This appeared to be preventing HTTP 1.1 range requests and I saw my file loading all at once. This was in Safari 12.

cURL confirmed that my host (firebase) could handle the range requests and send back HTTP 206 status codes.

I added ?nocache=1 to my HTML5 audio tag URLs and saw that I was getting successful range requests. This appears to be a way around the service worker issue.

Adjusting the default for common file types could help others and provide a better out-of-the-box experience. Alternate solutions could be adding to documentation or doing nothing.

jgierer12 commented 5 years ago

Hmm, based on this it should already exclude any URLs with extensions:

https://github.com/gatsbyjs/gatsby/blob/7c826a17219053421a85a75038474843f581e026/packages/gatsby-plugin-offline/src/gatsby-node.js#L83-L92

johnelliott commented 5 years ago

Hmm is that for the white list or black list?

johnelliott commented 5 years ago

I may be misunderstanding, but using regex101.com I didn't see .mp3 matching either of the regular expressions that the plugin has for the whitelist or the blacklist. Perhaps I am not trying a proper URL string.

jgierer12 commented 5 years ago

Yes that's the point. The service worker should ONLY cache URLs that match the navigateFallbackWhitelist, unless it also matches navigateFallbackBlacklist. some-file.mp3 doesn't match the whitelist, so the worker shouldn't even consider caching it.

Edit: To clarify, these are options for workbox-build.

jgierer12 commented 5 years ago

Could you put up some demo code where this behavior can be reproduced?

johnelliott commented 5 years ago

Thank you. I did see where the options went, I just read the effects backward. I think I will just close this. Iā€™m just glad folks can now search this in closed issues if the question arises for others.

jgierer12 commented 5 years ago

I'm not sure if this should be closed yet: If the whitelist regex doesn't match your media URLs, then why is the service worker intercepting them? Maybe I am just misunderstanding you, does it work now without ?nocache=1?