Scope of Server Push

Currently, browser implementations of Server Push will not inject the pushed response into the HTTP cache until there is a reference to it from the stream that the PUSH_PROMISE was sent upon. Reportedly, Firefox ties the affinity of a push to a "load group", whereas Edge is using a "navigation handle."

It's not totally clear whether this is:
 - a completely separate, non-HTTP cache
 - a modification or addition to the HTTP cache itself
 - a secondary level of HTTP caching with special usage rules
 - etc.

AIUI there are also variations about the scope of reuse itself; e.g., whether you can push an HTML page to the browser and have it use that from cache  if the user clicks on a link.

Right now, the requirements about HTTP caching and push are written as if the HTTP cache itself is fulfilling this role. E.g., RFC7540, Section 8.2 says:

> Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present (RFC7234, Section 5.2.2)) while the stream identified by the promised stream ID is still open.

Looking through the history, this text was written this way mostly so that pushed responses could use the HTTP cache as a kind of rendezvous with requests from the page. That may be sensible, but it feels like the specification of the relationship of push to the HTTP cache isn't complete (and I'll also start a separate thread about other aspects there).

I think there's an opportunity to clarify this, either in terms of HTTP caching, or browser behaviour (see <https://github.com/whatwg/fetch/issues/354>), or both. 

Furthermore, at the Workshop, there was some discussion about whether having this kind of "server push cache" as seperate from the HTTP cache was necessary; do we have any more data about why implementers feel it's necessary to have a reference from the page before insertion into the HTTP cache?

Discuss.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 24 August 2016 04:55:31 UTC