From 2559582a997a977e43ca2d345f3b3c1164a95885 Mon Sep 17 00:00:00 2001 From: Ilya Grigorik Date: Wed, 23 Nov 2016 15:28:15 -0800 Subject: [PATCH] response cache and matching lives in Fetch 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: https://github.com/whatwg/fetch/issues/354 Closes #30. --- index.html | 52 ++++++++++++++++++++++------------------------------ 1 file changed, 22 insertions(+), 30 deletions(-) diff --git a/index.html b/index.html index 958e3c7..40f4862 100644 --- a/index.html +++ b/index.html @@ -229,33 +229,25 @@

Processing

  • If the load was successful, [queue a task] to [fire a simple event] named `load` at the [link] element. Otherwise, [queue a task] to [fire a simple event] named `error` at the [link] element.
    • -
  • Add request to preload response cache (TODO). -

    TODO: define preload "response cache". Conceptually - this should probably reuse [SW's cache - logic](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#cache-objects)? - In effect, the preload cache is a UA maintained response cache with a - few interesting lifetime + eviction quirks.

    +
  • Add request to fetch group's response cache. +
    +

    In addition to the HTTP cache, all browser implementations + provide one or more levels of additional caches, which sometimes + live before the HTTP cache (e.g. HTTP/2 server push responses are + typically not commited to HTTP cache until a client request is + made), and after the HTTP cache (e.g. in-process memory caches). + These caches are not defined today and need to be defined in Fetch + API— see [related + discussion](https://github.com/whatwg/fetch/issues/354).

    +

    Conceptually, a preloaded response should be committed to the + HTTP cache, as it is initiated by the client, and should also be + available in the memory cache and be re-usable at least once within + the lifetime of a fetch group.

    +

    • The user agent MUST NOT automatically execute or apply the resource - against the current page context, and the user agent MUST retain the - fetched response until it is matched with another request, or is no - longer valid.

    -

    To match a preloaded response, the user agent must run the - following steps:

    - + against the current page context.

    For example, if a JavaScript resource is fetched via a preload link and the response contains a `no-cache` directive, the fetched response is retained by the user agent and is made immediately @@ -356,11 +348,10 @@

    Server Push (HTTP/2)

    HTTP/2 ([[!RFC7540]]) allows a server to pre-emptively send ("push") responses to the client. A pushed response is semantically equivalent to a server responding to a request and, similar to a preloaded response, is - retained by the user agent and executed by the application when - matched with another request - initiated by the application. As such, from an application perspective, - there is no difference between consuming a preload or a server push - response.

    + 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.

    The server MAY initiate server push for preload link resources defined by the application for which it is [authoritative][]. Initiating server push eliminates the request roundtrip between client and server @@ -411,7 +402,8 @@

    Early fetch of critical resources

    penalty. To address this, the application can use a preload link to declaratively specify which resources the user agent must fetch early to improve page performance:

    - 
    +      
     <link rel="preload" href="/assets/font.woff2" as="font" type="font/woff2">
 <link rel="preload" href="/style/other.css" as="style">
 <link rel="preload" href="//example.com/resource">