Hey @fauresebast, what would be the use case for having custom headers in asset responses and what headers would those be? Maybe we could add some of those as defaults?

Hello @brenogazzola, I found this to be necessary when working with service workers. On development setup, when delivered via propshaft, they will be under /assets/ path but if you register the service worker from / you'll get an error as the scope doesn't match.

Uncaught (in promise) DOMException: Failed to register a ServiceWorker for scope ('http://localhost:3000/') with script ('http://localhost:3000/assets/sw-v0000001.digested.js'): The path of the provided scope ('/') is not under the max scope allowed ('/assets/'). Adjust the scope, move the Service Worker script, or use the Service-Worker-Allowed HTTP header to allow the scope.

On production this isn't an issue as you can configure nginx to add the Service-Worker-Allowed header or if you serve static assets via rails you can use config.public_file_server.headers

I have a similar change on a fork to bypass this limitation: ylecuyer@55ea5f3

I've hit that service worker issue as well, but it seems a bit much to send that specific header with every asset request, no? Although maybe it's not a big deal.

Also, I think we should probably just configure this header by default in an exposed configuration point, so service workers can be served by Propshaft out of the box.

We chose to follow your idea:

Also, I think we should probably just configure this header by default in an exposed configuration point, so service workers can be served by Propshaft out of the box.

And made the changes.

Would other users want to set something other than /? I think David meant something like config.assets.prefix, not a boolean that adds or not the fixed / path?

@brenogazzola done

Hmm, I don't love this being service worker specific. Propshaft shouldn't know anything about specific files, types, or whatever. If we need to add/change headers, it needs to be a generic interface.

As it specifically pertains to the server-worker file at the root, we've gone this way for Rails 8: rails/rails#50528

We've added default PWA files that are routed through a controller in Rails now. I think that's a better solution.