
HTTP/2 Server Push - rakyll
https://blog.golang.org/h2push
======
hdhzy
It's still not clear to me what problem is Server Push solving. If it's early
delivery of associated resources (css for html page) then the client could
already have a cached copy of that CSS (e.g. previous visit). It's possible
for the client to cancel PUSH_PROMISE but then the server could have already
sent some data. So it's double work for both the client and the server.

I'd be personally interested in having programmatic access from Javascript to
pushed resources (maybe emulating Websocket?).

~~~
chucke
It's mostly a trade-off of what's more important to you: round-trip or bytes.
The client might have a cached-copy, but it must (in most cases) revalidate it
by requesting with cache-headers and getting back that empty 304 response. The
round-trip cost depends of the actual scenarios, but the fact is that some
resources, like css in <head> will block rendering. So you might have some
better results by speculatively pushing the critical rendering path.

You can also speculatively push 304 responses btw, which would have the same
effect in your described scenario minus the round trip. How you figure out if
the client has fresh cached resources, that's still an unsolved problem. You
can program it yourself in some servers. H2O server has its own mechanism for
that. There's also an RFC for Cache Digest Assets frame that might extend
HTTP2: [https://tools.ietf.org/html/draft-ietf-httpbis-cache-
digest-...](https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-00)

