Sec-Fetch-Dest header polyfill for Safari?

[andreawyss]

Question

Could a service worker implement the Sec-Fetch-Dest header for Safari or add a different header when requests are initiated from an iframe vs. top window?

Problem

Currently Sec-Fetch-Dest header is implemented by all browsers except for Safari and Safari on iOS.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest

Solution

Write a service worker that adds a headers to all requests which value informs if request was initiated by a document inside an iframe or by the document in the top window.

Assumptions & Constrains

Top and iframe documents are on the same origin.

A same iframed document can also be loaded at the same time in a different browser's tab unframed (as a top document).

The server needs to generate a different page layout when a document will be shown by itself (Top document) or when shown inside an iframe.

We don't want to send the same document and then modify it on the client side based on top === self because the version for the iframe is faster to generate and puts less load on the server. The full version for the top window is heavier and slower to generate.

We can add code to the top document.

We can and add code to the iframed document.

Ask for Help

@kettanaito with your deep knowledge of service workers is there a way to achieve this?

Thank you for any help, suggestions or directions on what may be possible.

[kettanaito]

Hey, @andreawyss. It's nice to hear from you!

According to the docs, the Sec-Fetch-Dest header is a Forbidden header. This means that it cannot be set manually on the request/response instances.

All headers which names start with Sec- are forbidden. Hence the prefix Sec-, "secure".

You can try it out yourself:

const req = new Request()
req.headers.set('Sec-Fetch-Dest', 'iframe')
req.headers.get('Sec-Fetch-Dest') // null

The only legitimate source for this header is the browser itself. If it doesn't set it, there's nothing we can do to polyfill this on our side.

Even if we could, I'm afraid this request falls outside of what MSW should do. It's, essentially, about adding a browser feature to the browsers that don't have it. It's not even related to mocking requests, only utilizing Service Workers to augment them. We are unlikely to consider such changes, as it's not the library's goal/promise. You can, however, write a custom worker that'd modify requests to your liking (hey, you can even compose workers with importScript!).

[andreawyss]

@kettanaito Thank you for the response.

What I was seeking advice from you, was if it is possible for a service worker to make decisions based on the window the requests are coming from.
Maybe using the window.name property or other identifier.

And please, let me know where is best place on the internet to ask this service worker question.

Thank you.

[kettanaito]

I think you can achieve that by looking at the controlled client of the request.

The FetchEvent argument you get in the "fetch" event listener contains the clientId. You can use that ID to retrieve the WindowClient object that made the request:

// worker.js
self.addEventListener('fetch', (event) => {
  const client = self.clients.get(event.clientId)
  console.log(client)
})

interface WindowClient {
  focused: boolean
  frameType: string // indicates if the client is a main window / iframe / else.
  id: string
  type: string
  url: string
  visibilityState: VisibilityState
}

You can write a conditional logic based on the client's properties (i.e. respond to the request differently based on the client's frameType).