Define preload cache and request matching algorithm

[igrigorik]

Relevant sections:

• https://w3c.github.io/preload/#dfn-preload-resource-has-been-obtained
• https://w3c.github.io/preload/#dfn-match-a-preloaded-response

[igrigorik]

From: https://groups.google.com/a/chromium.org/d/msg/blink-dev/_nu6HlbNQfo/OAzGqQa8BgAJ

if you preload something and another request gets there through a redirect, does it end up using the preloaded resource? (And is that response then changed to account for the possibly mixed content violating redirect?)

I think these will be answered once we resolve this bug, which is about defining the matching algorithm within Fetch. A really high-level overview of what I'm thinking:

• we define a new response cache (name TBD, because we want it to be reused across preload, prefetch.. and probably even h2 server push'ed resources?)
• preload inserts resources into this cache
• fetch checks this cache prior to firing events at the SW/network/disk-cache

/cc @annevk @yoavweiss

[mnot]

That sounds sane-ish. H2 server push is already kept separate until it's actually referenced from content.

/cc @mcmanus

[annevk]

I think it would be good to actually leave this open until it is properly defined.