Response cache and matching lives in Fetch #79
Conversation
Preload response's are one of several responses that interact with the (yet to be formally defined) response cache. As such, the logic for both populating and querying said cache should live in Fetch. - Updated issue text as a warning, with some context and pointer to the discussion in Fetch. - Removed "match a preloaded response" definition: this should be handled transparently by Fetch, as one of the first steps in its main fetch algorithm. Fetch issue where we should continue this discussion: whatwg/fetch#354 Closes #30.
| In effect, the preload cache is a UA maintained response cache with a | ||
| few interesting lifetime + eviction quirks.</p> | ||
| <li>Add request to fetch group's response cache. | ||
| <div class="advisement"> |
There was a problem hiding this comment.
Should we indicate that this is non-normative, or is the advisement class enough?
There was a problem hiding this comment.
Probably should.. I'll change the class to note and change up the verbs.
| retained by the user agent and executed by the application when matched | ||
| with a request initiated by the application. As such, from an application | ||
| perspective, there is no difference between consuming a preload or a | ||
| server push response.</p> |
There was a problem hiding this comment.
That's not entirely true. There's no difference between consuming an explicit preload (link preload based) and an implicit one (triggered by preloadScanner). There is a difference with H2 push though - consuming H2 push involves marking an RT entry, going through SW, and querying the HTTP cache before the H2 push response is matches with the request at the net stack layer.
There was a problem hiding this comment.
True, for Blink's implementation today.. and there is ongoing discussion(s) as to whether that should remain as is - e.g. if we actually trigger push events in JS land, then all this will obviously have to change.
For an application, both paths will trigger SW lookup, HTTP cache lookup, etc. Yes, there is difference in when those things happen, but that's mostly due to internal (unspecified) implementation bits. As such, I'm inclined to keep this as is.. at least until we all converge on some standardized treatment of h2 push in our specs.
|
Overall LGTM. Added a couple of comments |
Preload response's are one of several responses that interact with the
(yet to be formally defined) response cache. As such, the logic for both
populating and querying said cache should live in Fetch.
discussion in Fetch.
handled transparently by Fetch, as one of the first steps in its main
fetch algorithm.
Fetch issue where we should continue this discussion:
whatwg/fetch#354
Closes #30.