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?).
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-...
2 comments
[ 4.3 ms ] story [ 16.8 ms ] threadI'd be personally interested in having programmatic access from Javascript to pushed resources (maybe emulating Websocket?).
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-...