Re: Scope of Server Push

[Tom Bergan <[e-mail]>]

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

Nit: The last part of this sentence is too strong (should be "connection",
not "stream", at least for Chrome).

> Reportedly, Firefox ties the affinity of a push to a "load group",
whereas Edge is using a "navigation handle."

Chrome uses a per-H2-connection cache for pushed responses. There is a very
related discussion going on in this thread:
https://groups.google.com/a/chromium.org/d/msg/net-dev/CCNLknIbzYs/yNmiUaHQAQAJ

On Tue, Aug 23, 2016 at 9:55 PM, Mark Nottingham <[e-mail]> wrote:

> 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/
>
>
>