So wait, if the server pushes assets before the client request it, does that mean the server pushes them regardless of the cache status on the client?
If so that should really be limited to small assets to be beneficial
If so that should really be limited to small assets to be beneficial
According to the spec, browsers have the ability to abort pushes that the server has started, so if you start sending down a 3MB file, your browser can send the server a request to stop sending it, because it's already in cache, but no browser actually does this today, and the first part of the file gets sent down regardless.
There's a draft spec for browsers to use "Cache Digests," a compact representation of the content already in the cache. http://httpwg.org/http-extensions/cache-digest.html But no browsers support that today.
Luckily, you can workaround/polyfill Cache Digests using Service Workers. Your Service Worker can provide the Cache Digest as a custom HTTP header on subsequent requests, and then the server can know to avoid re-pushing cached resources.
Alternately, and more simply, if you configure your Service Worker to return/render stale content on first load, your Service Worker can make a request in the background to fetch the latest content, passing a simple header to the server to disable push. Since the stale content has already rendered, the round-trip time to download updated resources is less important.
http://calendar.perfplanet.com/2016/cache-digests-http2-serv...
[1]: https://h2o.examp1e.net/configure/http2_directives.html#http...
Are browsers really not doing this? My understanding was that just one round-trip was wasted for the client to send an RST_STREAM frame, or does it really re-download the entire pushed file where normally it would be a 304 on request?
So why not? Priorities. Not very many sites are using push, and this is partly due to a chicken-and-egg problem; push isn't that good, so nobody's uses it, so there's not much incentive to make push better.
But even if new browsers started correctly aborting pre-cached pushes today, that still wouldn't be as awesome as Cache Digests, which could avoid re-pushing cached content without wasting any bytes. So, if you're going to spend a few minutes working on H2 Push, you should probably spend it working on Cache Digests, rather than working on aborting pushes.
And Cache Digests can even be polyfilled by Service Workers, which are incredibly powerful in their own right. So if you're not Chrome or Firefox, rather than even spending time on Cache Digests, you should probably focus on implementing Service Workers first, so the users can at least polyfill their way out of the problem.
So the order should be: Service Workers first, then Cache Digests, then push-aborts. So, uh, don't expect to see any push aborts from the major browsers any time this year, IMO.
The server will send a "push promise" which basically says "I'm going to send this file to you", and then the client can come back and say "don't bother, I already have it". And this all happens in parallel with the download of other assets (like the main page), so it doesn't really slow anything down.
Here's an article I read which goes into how server push works in a lot more detail: https://hpbn.co/http2/#server-push
The client requests some page (e.g. index.html), which will trigger the push on the server. E.g. one for asset1.png. The server initiates the push by sending a push promise frame down the wire, which contains the content of a simulated HTTP request for that exact resource - like if the client sent a GET request for asset1.png through a headers frame. The client can only react on this frame when it receives it and sees that it has asset1.png already in cache. It can then cancel the stream by sending a ResetStream frame. However obvisouly that takes some time, until this push promise frame arrives at the client. Meanwhile the server might decide to not only send the push promise header, but also parts of (or the complete) data. So asset1.png already goes down the wire, and blocks bandwidth that could be used for other things too.
In the worst case scenario with server-push that you described, the server decides to push content the client already has cached before pushing content the client doesn't have, and begins transmitting that redundant content before the client has a chance to cancel the push. Once the client receives push promises for the content it doesn't need, it can immediately send a request to cancel the download of those resources. Once those cancellation requests reach the server, it immediately stops transmitting the resources the client has cached, and starts transmitting the data the client actually needs.
Contrast this with the same scenario without server push, where the client parses the HTML for the main page to determine what resources it needs, then send requests for those items which the server must receive before it starts transmitting them. In both cases a round-trip from the server to the client and back is needed before the server can start transmitting the necessary assets, but without server push the client needs to download and parse the main page before it can start telling the server which resources it needs, whereas with server push it can send cancellation notices before the current page is downloaded or parsed.
https://www.shimmercat.com/en/blog/articles/whats-push/#inte...
Sounds painful to me.
In practice, it's going to be a lot faster than the default of not pushing resources.
Without server push:
1. Client requests main page ->
2. Client receives main page <-
3. Client requests subresources ->
4. Client receives subresources <-
With server push:
1. Client requests main page ->
2. Client receives push promises and main page <-
3. Client cancels promises it doesn't need ->
4. Client receives subresources <-
The only difference is that with server push, steps 2, 3 and 4 happen in parallel, and step 3 can be omitted entirely in the event that the client doesn't need to cancel any pushes.
Without server push:
1. Client requests main page ->
2. Client receives main page <-
With server push:
1. Client requests main page ->
2. Client receives push promises and main page <-
3. Client cancels promises it doesn't need ->
Assuming the server has no way of determining which assets the client has cached (which depending on implementation may not be the case) you're of course correct. However, after step 2 the page has already fully loaded in both cases, so step 3 doesn't really slow anything down.
If, on subsequent requests, the cookie is sent along with the request, H2O doesn't send those files.
This is still a bit of a hack, and ultimately browsers will have to include some information on what's in the actual cache, with proposals on that pending: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-di...
As others have said, there are workarounds using cookies. Which is yet another abuse of a very bad feature of HTTP.
"When the user navigates to a subsequent page that requires that asset, it can be pulled from the cache, eliminating the need for additional requests to the server."
I'm not clear on if there is any relation to existing cache headers. I would have thought even the first page hit could have Link'ed assets pulled from the cache if present (if the client had previously visited that push-enabled resource (edit: in which case it's not the first I guess zzz). I guess the client, upon hitting a cached asset referenced in a Link header ignores it where otherwise it'd suck it down the socket as part of the same initial request.
Push should only be used for updates, including updating the cache. Ideally you'd only be sending the deltas (changes).