Scope of Server Push

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Scope of Server Push

Mark Nottingham-2
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/


Reply | Threaded
Open this post in threaded view
|

Re: Scope of Server Push

Alcides Viamontes E-2
Two quick comments.

The first is related to the "rendezvous zone"... how long are things expected to be kept there? 

The second has to do with a use case that I think falls into a gray zone: using Push as a "good" way of doing HTML inlining.  Just to dust it off, say that the HTML file goes like this:
...</div><!--point-->
<script src="nugget.js"></script>
</body>
</html>


The server may want to push 'nugget.js' as a way to save a round-trip. At first instinct one would like to send the push promise either immediately before the HTTP headers for the HTML stream, or immediately after. But piling too many push-promises  close to the start of the TCP connection may trigger a round trip. 
An alternative is  to architect the DATA frames for the HTML so that there is one terminating at "point", insert the push promise for nugget.js there (if the server knows, e.g. via cache digests, that the client doesn't have "nugget.js"), and only then continue sending the HTML data frames.  

Notice that this is the same use case that has been imagined for Push, and I have reviewed RFC 7540 to see if this contradicts the spec in some way and so far I think it doesn't. It is just sending the push promise as late as possible to avoid congestion round-trips. There is no need to do this for pages that only require a few scripts to be pushed, but if developers are going to stop concatenating assets, the number of smallish Javascript and other files one may need to push to get a quick first render grows very quickly, we have seen this happen in some of our sites. 

Waiting as much as possible to send push promises would also work nicely with the current cache digest proposal, as the server gets more time to receive any cache digest frames in flight from the browser.

Sending push promises just before the links embedded in DATA frames  may or may not work today, since there is no hard requirement for browsers to mix links scanned from the HTML contents with links arriving in push promises as strictly and eagerly as possible. It would be nice to account for this use case in any future precisions to HTTP/2 push.


On Wed, Aug 24, 2016 at 6:55 AM, Mark Nottingham <[hidden email]> 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/





--
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)
Reply | Threaded
Open this post in threaded view
|

Re: Scope of Server Push

Tom Bergan
In reply to this post by Mark Nottingham-2
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:

On Tue, Aug 23, 2016 at 9:55 PM, Mark Nottingham <[hidden email]> 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/