Repository navigation
Preserve sec-fetch-dest for passed navigate requests #1803
Description
For navigate requests the sec-fetch-dest header is set to document. Once a service worker is introduced that simply forwards the request to the network, the sec-fetch-dest header changes to empty.
There are systems that rely on that header on server side to detect navigate requests and act accordingly. Shopify for example has some language/currency persistence logic that uses it.
Introducing a service worker that forwards requests (e.g. to cache responses for offline handling), breaks functionality.
I would argue that a navigate request from the browser should behave the same when proxied through a service worker. If this cannot be assumed by the developer, it gets very hard to implement service worker without potentially breaking functionality.
To have a reproducable example, here is a test website: https://dm-clone-optimized.app.baqend.com/fetch-dest/
It installs a service worker and when reloading you can see the sec-fetch-dest header being different depending on whether you bypass the service worker or not.
Activity
asutherland commentedon Nov 7, 2025
I understand the problem here to be that the destination is not propagated by the Request constructor as invoked by fetch(). This probably should be discussed in the fetch spec, although any changes might eventually involve the ServiceWorkers spec.
whatwg/fetch#1323 seems like it may be the most directly related open issue, with whatwg/fetch#1762 touching on it tangentially. @annevk probably has more useful thoughts.
annevk commentedon Nov 20, 2025
It's hard as the service worker can replay these responses anywhere. There's no guarantee that a response to a navigation won't be delivered to a
<script>. #1395 has some musings, but I think there are even earlier musings on this topic that go a bit more into the challenges.wanderview commentedon Nov 20, 2025
Random brainstorming: The request could track the original navigation internally. If a fetch is made with the request while the original navigation is outstanding, then sec-fetch-dest is passed through. Otherwise is reverts to empty string.
This would be hard to understand and the request would no longer really be immutable, though.
asutherland commentedon Nov 26, 2025
One possibility is to alter the optional ServiceWorkerAutoPreload mechanism introduced in #1756 based on the https://github.com/WICG/service-worker-auto-preload proposal that's built on the "race response" mechanism so that 1) sec-fetch-dest gets passed through and 2) it's not optional since the fetch then would be different and webcompat demands all browsers implement that.
yoshisatoyanagisawa commentedon Dec 1, 2025
Thank you for your thoughts, @asutherland.
I agree that this is a broader issue for the Fetch specification. It's worth noting that the potential for a service worker to replay a navigation response is not a new risk introduced by features like
ServiceWorkerAutoPreload. This possibility has existed sinceNavigationPreloadwas introduced.This seems to reinforce the ideas discussed in whatwg/fetch#1323, such as adding a new header to indicate to the server that a service worker is involved.
fix iframe cat (X-Frame-Options deny): loader /app nunca 302 para URL…
Show a private app's sign-in page through its install worker, so a la…