Re: Scope of Server Push

[Alcides Viamontes E <[e-mail]>]

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


-- 
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
([phone]
(www.shimmercat.com is a property of Zunzun AB)