Worker client hint set should be updated at some point?

[amtunlimited]

I just noticed that a worker's client hint is set at initialization, but workers can live beyond multiple top-level navigations. We should decide if/when/where a worker's client hint set is updated/reinitialized

[wanderview]

I believe service workers should probably be treated like their own top level "document" for client hints. They are not associated with any single other document and can exist without a document at all.

It would probably be most straightforward to give the service worker client hints based on Accept-CH headers on the service worker script response itself. Since the response is persisted, these could be applied every time the script is loaded. Sites would have to update their script to apply new CHs to the service worker.

This would allow sites to explicitly control the CHs for fetch's made during the service worker install event and arbitrary other fetches from the service worker. If the service worker does fetch(FetchEvent.request), though, the CHs for that request should come from the FetchEvent.request.

If necessary we could also consider possibly making changes to the Accept-CH headers trigger the installation of a new script. Right now we only install a new service worker version if the bytes in the body of the script change.

[wanderview]

I would also recommend doing the same for SharedWorker since its list of associated documents may change over time.

I'm less opinionated about DedicatedWorker, but it would be nice to be consistent there. It would also automatically handle the case where DedicatedWorkers are nested under SharedWorker or ServiceWorker in the future (something we want to support).

[amtunlimited]

cc @davidben @yoavweiss