You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Requests for service worker script's update may not have request's initiator as like user initiated navigation since it may not be triggered by sites.
I'm guessing 'none' is an appropriate value for the Sec-Fetch-Site header for that case.
The text was updated successfully, but these errors were encountered:
This is an interesting case. Is the service worker update request sent for the same URL from which the original SW is loaded? If so, I'd consider this to be a same-origin request because the origin which installs the SW controls the URL to which the update request is later made by the browser.
(I also have nothing against none if that seems to make more sense here.)
Yeah, the URL of a request to update a service worker is the same with the origin of the original SW and also the same with the origin of the page which called navigator.serviceWorker.register("sw.js"). same-origin sounds reasonable too.
Btw, I also found that we need to set request's origin to the origin for the main script. IIUC, it will automatically fix this issue. w3c/ServiceWorker#1447
I agree that same-origin is fine here, as service workers need to be same-origin, and the update request can reasonably be considered an extension of the origin's initial registration.
It sounds like this only requires a change in the Service Worker spec, which @makotoshimazu already filed. Closing this out in favor of that. :)
Requests for service worker script's update may not have request's initiator as like user initiated navigation since it may not be triggered by sites.
I'm guessing 'none' is an appropriate value for the Sec-Fetch-Site header for that case.
The text was updated successfully, but these errors were encountered: