Comment by dfabulich | Hacker News Reader

Comment by dfabulich | Hacker News Reader

Parent Full thread

You are precisely correct; server push is not cache aware today.

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

Some web servers[1] additionally stores cache information in cookies. The same author that (co-)wrote your linked draft implemented it as a primer to the draft. If only CDN's supported it :-)

[1]: https://h2o.examp1e.net/configure/http2_directives.html#http...

> but no browser actually does this today, and the first part of the file gets sent down regardless.

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?

The RST_STREAM frame is, indeed, how the browser was supposed to abort the download, per the spec. But it's a SHOULD, not a MUST. In fact, browsers just don't do it.

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.

Reply on news.ycombinator.com