Define a cache for H2 server push & friends

[annevk]

We have several features that interact with some cache that is not really defined:

• rel=prefetch
• rel=preload
• H2 server push

I think the approximate semantics we want are HTTP cache semantics. However, resources that cannot be cached should only survive the lifetime of the fetch group and can only be fetched within the scope of that fetch group (once?).

[jakearchibald]

I agree with your thinking here.

On document-insertion <link rel="preload"> creates an entry in the fetch group's "preload cache" containing the request and a promise for the response. Should we do this for no-store responses too? Like all requests, their fetch goes through the service worker with a "default" cache mode.

Then before step 3 of https://fetch.spec.whatwg.org/#http-fetch: (with lots of hand-waving)

1. If the request mode is not "navigation":
   1. For each entry in the client's fetch group's "preload cache":
      1. If the request's url and method matches the entry's request
         1. Let preloadResponse be the result of waiting for the entry's response promise
         2. If this entry is no longer in the fetch group's "preload cache", skip to the next iteration of the for-each (trying to catch races here)
         3. If preloadResponse is a network error (do we want to do this for 404s etc too?)
            1. Remove this entry from the "preload cache"
            2. Skip to the next iteration of the for-each
         4. For the vary header in preloadResponse, if request and the entry's request match up
            1. Remove this entry from the "preload cache"
            2. Return preloadResponse

H2 server push

Can these be easily associated with a fetch group? I thought a single H2 connection would be used for multiple pages.

[jakearchibald]

In the above I'm trying to ensure that the preload cache is used even if the request is still in-progress.

[annevk]

@jakearchibald a H2 server push is part of an HTTP response to an HTTP request. So it can only exist as part of a single request-response stream and not on its own. So therefore you should always be able to associate the push promises with a fetch group.

[jakearchibald]

You're right, the PUSH_PROMISE has a stream ID for itself along with the stream ID for its data. In that case I agree that it should match <link rel="preload">.

I believe we don't allow pushed items into the HTTP cache until they're "used". This doesn't make a whole lot of sense to me, but maybe @igrigorik can explain why.

[bzbarsky]

However, resources that cannot be cached should only survive the lifetime of the fetch group

That's not correct in the case of <link rel=prefetch>.

@annevk, please make sure that you talk to some of the network team folks at Mozilla about this; I'm not going to have the bandwidth to be involved in this conversation...

[jakearchibald]

It'd be a lot simpler if prefetch only populated the HTTP cache (unless no-store etc). prerender is already confusing in terms of security w3c/resource-hints#63.

[jakearchibald]

https://groups.google.com/a/chromium.org/forum/#!topic/loading-dev/GoONR_xSGJ4

In Chrome, pushed resources don't enter the http cache unless they're matched up to a future request.

As a developer, this is pretty unexpected, but I'm keen to hear from other vendors.

[annevk]

When this was discussed during the HTTP workshop vendors seemed to be open to changing this. After all, if you want to fill up the HTTP cache there's plenty of ways to do so already. So not letting H2 server push near it is weird. The uncacheables would get the lifetime of the fetch group, per OP.

[sleevi]

@annevk I'm curious what's intended by the fetch group semantics, as I don't believe that's something implemented in Chrome (nor easily implemented). The closest parallel I can think is if it's meant to be the abstraction layer detailing how our renderer process works (and the relationship to the renderer-side memory cache), but if that's the case, then it certainly is not part of our implementation or notion of Fetch, nor would I be keen (nor would it be possible) to hang more stuff off it.

I think I'd disagree with @jakearchibald on the relationship between PUSH and the cache being weird, and it may simply have to do with the choice of verb attached to it implying a semantic meaning unmet by implementations; that is, had it been called, say, OPPORTUNISTIC_RESOURCE, would that have made it clearer or not? I'm not aware of any implementation letting H/2 into the cache, and while that may be something to discuss, I absolutely want to make sure we don't entangle it with the notion of fetch groups unless/until we have a solid understanding of what they're trying to describe or prescribe. I'm not sure if this is exactly the right bug to hash it out, and I suspect I'd need to rope in a few colleagues to make sure we're accurately describing it, but for now, I'd like to separate out protocol-handling discussions (e.g. H/2) from "Fetch/Web Platform" level discussions (e.g. prefetch, preload; whether or not that's a fair characterization I'm not sure, but that's certainly reflected in how Chrome has implemented them and architected around)

[annevk]

A fetch group is something that manages all the fetches for a document or worker and has a similar lifecycle. The precise details are still a little unclear, but we need something like that to define what happens when navigating and such.

I think it would be fine to discuss H2 server push separately from prefetch and friends. We could first try to sort out the latter and then see how to improve the former. There's also an open JavaScript API question around H2 server push that at some point will come to a head and we have better figured out the layering by then.

[wanderview]

Comment on "fetch group", sorry if its off topic:

One thing we have not had to deal with in FF so far are fetches in the same fetch group (we call it a LoadGroup) that are triggered from different processes. We will have to figure this out as we move to a more multi-process architecture. But this might explain some differences between FF and chrome today. Perhaps we will end up looking more like chrome here for pragmatic reasons.

If we want to add functionality to fetch group we need to think about how they work across process boundaries. I guess its more of an implementation concern, but it will restrict what can be realized from the spec.

[jakearchibald]

I've typed this a few times over the past weeks, and deleted it, so it's probably still a bad idea.

The "list of available images" has a lot of similarities to the preload cache. The differences are:

• Items aren't discarded after use, they keep matching
• The image cache can transfer between navigations

We could try and merge these. link[rel=preload] could add options to persist the item in the cache after usage, or allow the item to persist across navigations.

[wanderview]

I think a difference between something like image cache and preload cache is where they are tied into the stack. In my fuzzy view of the universe:

• Preload cache is consulted at the network layer, similar to http cache. This would be below the service worker.
• Image cache is consulted at the DOM layer by element loading, etc. This would be above the service worker.

Maybe that is an incorrect view of the world. I think if we want these caches to be spec'd similarly, though, we may want to align where they are accessed in the stack.

[jakearchibald]

I think the intent is for the preload cache to sit with the fetch group, so preload requests go through the SW.

H2 cache is currently at the network level in Chrome though.

[rektide]

There's also an open JavaScript API question around H2 server push that at some point will come to a head and we have better figured out the layering by then.

For reference, #51 seems to be the general H/2 push topic and #65 has one way of fulfilling that, an observer api.