Unfortunately, this won’t work either, because the ways the browser fetches a resource to be displayed in an iframe on an existing page versus as a new top-level page have diverged. For example, browsers either don’t send cookies in third-party contexts or won’t soon, and if you are prefetching a resource from a different site the first example is third-party while the second example is first-party.
Similarly, browsers that support Sec-Fetch-Dest explicitly tell the server what context the resource they are fetching will be displayed in:
// Top-level navigations' destinations are "document"
Sec-Fetch-Dest: document
// <iframe> navigations' destinations are "iframe"
Sec-Fetch-Dest: iframe
Overall, this means that if you wanted to have prefetch work for both of these you would be requiring prefetch make two separate requests to the server when the developer almost always could tell you which one of the two they needed.
Yeah, additional requests definitely defeat the point.
I suppose, any other attempts to solve this on the browser side make no sense either, because of same safety concerns that caused the problem in the first place? In which case it looks like your solution is the only reasonable way to go.
Unfortunately, this won’t work either, because the ways the browser fetches a resource to be displayed in an iframe on an existing page versus as a new top-level page have diverged. For example, browsers either don’t send cookies in third-party contexts or won’t soon, and if you are prefetching a resource from a different site the first example is third-party while the second example is first-party.
Similarly, browsers that support Sec-Fetch-Dest explicitly tell the server what context the resource they are fetching will be displayed in:
https://www.w3.org/TR/fetch-metadata/
Overall, this means that if you wanted to have prefetch work for both of these you would be requiring prefetch make two separate requests to the server when the developer almost always could tell you which one of the two they needed.
Thanks for your answer!
Yeah, additional requests definitely defeat the point.
I suppose, any other attempts to solve this on the browser side make no sense either, because of same safety concerns that caused the problem in the first place?
In which case it looks like your solution is the only reasonable way to go.