Where should you store it in your cache? Well, it depends what the user is going to do. If they are going to click on a link to b.test/index.html, then when they need the HTML they will be visiting b.test and so you want to store it as b.test:b.test/index.html. On the other hand, if it’s going to load in an iframe, the user will still be on a.test and so you want to store it as a.test:b.test/index.html. You just don’t know. Just guess?
The guess is a risky one: if you store it under the wrong key then you’ll have fetch the same resource again just to store it under the right key. Users will see double fetching.
Is there an option for browsers to fetch the resource once, but store it under both possible keys? What would be the downside for that?
What I really want to say—is there a way to fix the problem without changing the specification? Would it be too technically difficult? Too costly?
Changing specification is surely an elegant solution, but then you need everyone to learn about the changes, and implement it in their work, and I feel like that process is always slow and painful and html specs are so complicated already. And then there are so many websites that are already developed but are not supported properly.
I’m not a web developer, my understanding of this problem is very surface-level—I apologize if my questions sound stupid to you.
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.
Is there an option for browsers to fetch the resource once, but store it under both possible keys?
What would be the downside for that?
What I really want to say—is there a way to fix the problem without changing the specification?
Would it be too technically difficult? Too costly?
Changing specification is surely an elegant solution, but then you need everyone to learn about the changes, and implement it in their work, and I feel like that process is always slow and painful and html specs are so complicated already. And then there are so many websites that are already developed but are not supported properly.
I’m not a web developer, my understanding of this problem is very surface-level—I apologize if my questions sound stupid to you.
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.