Re: [whatwg/fetch] Define the "Preload Cache" (#590)

I would like to suggest that there "preload" is not (or shouldn't be) defined as a cache at all, or at least not cache in the way we usually use the word, an ephemeral storage with a size limit and something like an LRU mechanism.

Rather, proposing this alternative, which seems roughly equivalent to how @mayhemer describes the Gecko implementation [here](https://github.com/whatwg/fetch/issues/590#issuecomment-648934087):

1. The document should hold a list of responses, 1:1 mapped to the `<link rel="preload" />` elements currently in the `head`.
2. If a `link` is modified, the response gets re-fetched, and if it's removed the response is discarded.
3. When requesting a preloadable resource (anything in the `as` list), the corresponding spec would first look for the URL in that preloaded response list (provided that it also has the same crossorigin characteristics etc), and use that response before trying to call `fetch`.

It puts the preload "cache" above the HTTP and SW caches, but below the resource-specific memory caches.

This would make it easier to clarify how preloads should behave when the `link` element changes or gets removed, or if there are strange scenarios (e.g. an image is preloaded, then used, then removed, then loaded again) - as long a preload link is currently in the document, its response is still accessible. 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/590#issuecomment-925218337