2

HTTP/2 server push enables pushing assets to clients which you anticipate they'll need in order to render the page. For example, you can push your CSS/JS/images to the client at the same time as you respond to a request for an HTML page, so they receive those assets sooner.

But how do you avoid wasting bandwidth on clients that already have the assets cached?

Does the server push mechanism handle this situation automatically, and how? Or does my serverside app need to somehow track clients that have already been served a response previously, and avoid server-pushing extra assets to those clients?

callum
  • 10,417

1 Answers1

2

Read the spec http://http2.github.io/http2-spec/#PushResources, it notes that cacheable responses will be cached, non-cacheable responses must not be cached.

If something is already in the cache, the client will be able to refuse the duplicate asset by sending a RST_STREAM frame: http://http2.github.io/http2-spec/#RST_STREAM.

See mark Nottingham's blog for more details:

https://www.mnot.net/blog/2014/01/30/http2_expectations

He also indicates that server push will allow the server to proactively invalidate the client's cache, i.e. push a new asset when the server asset has changed, which is a very useful feature.

Robert Munn
  • 1,281
  • That's interesting. So if the client 'refuses' it, does the server just stop mid-transfer? And doesn't this still waste a lot of bandwidth (depending on how quickly the server receives the refusal frame)? Compared to what we have now (where assets are only transferred the first time a new client visits your site, albeit with a round trip penalty), it sounds like server-pushing assets would be very bandwidth intensive. – callum Apr 09 '15 at 12:50
  • My assumption is that the client will refuse the transfer as soon as it sees the header information with the name/size of the asset. I don't know if how that works in practice is up to the individual client, but I have faith in the ability of the people writing the spec and the client/server software to implement it in a more efficient manner than HTTP/1 with round-trip penalties. – Robert Munn Apr 09 '15 at 22:21