HTTP/2 Server Push


#1

Would love to see support for HTTP/2 server push in your offering. This can be especially impactful with new JavaScript bundling strategies for SPAs.


#2

definitely a +1 :heart_eyes:


#3

Definitely a hot topic :slight_smile: However, the are a few questions that need to be answered first.

How does the browser cache pushed content?
Chrome seems to store the assets in a “session” cache, which means that the assets get dropped once the session has ended. The browser cache is extremely important to offload traffic.

How stable is HTTP/2 Server Push?
IMO, I would not call it stable yet. There are still some issues (bugs) here and there: https://bugs.chromium.org/p/chromium/issues/detail?id=491778

What is the best way to use Server Push in your app?
I have the feeling that we need to collect much more knowledge on how we can make the best with this new feature. Such as how efficient is the client in cancelling push streams? Which assets should be pushed to the client?


#4

How does the browser cache pushed content?
Chrome seems to store the assets in a “session” cache, which means that the assets get dropped once the session has ended. The browser cache is extremely important to offload traffic.

I believe this to be true only until a matching HTTP request is made for a pushed asset. For example:

  • the browser requests a.file
  • the server creates a stream for a.file and a push stream for b.file
  • a.file immediately goes into the web cache, and b.file goes into a session cache (unless cancelled)
  • if b.file is requested before the session ends, b.file will also enter into the web cache
  • otherwise, b.file will be dropped when the session terminates

How stable is H/2 Server Push?
IMO, I would not call it stable yet. There are still some issues (bugs) here and there:

This makes debugging slightly cumbersome in the client, but I don’t see why this would interfere with rolling out support on the server. The protocol itself is very stable, so far as I know.

What is the best way to use Server Push in your app?
I have the feeling that we need to collect much more knowledge on how we can make the best with this new feature. Such as how efficient is the client in cancelling push streams? Which assets should be pushed to the client?

Again, it is my opinion that the answers to these questions shouldn’t directly impact an implementation, so long as the CDN implementation provides a reasonably flexible API. In fact, I’d say that waiting on web app bundling and delivery patterns to emerge will result in a chicken-and-the-egg sort of problem. These standards won’t emerge until support is broad enough.

More to the point, a Pull Zone could remain completely separated from these concerns. If the origin responds with a Link header, the CDN should push those assets to clients making the request. This is how CloudFlare approaches it. That puts the responsibility for what to push solely on the origin, which provides significant flexibility to application authors.


#5

Push Zones are a bit harder. Since assets are uploaded via FTP or rsync, there’s no straightforward way to add meta-data directly to a given asset. Akamai uses a property manager to select push assets for a given request. This seems a bit clunky to me, since there doesn’t seem to be a way to do this other than through the web interface. Plus, the level of granularity provided isn’t ideal. However, I imagine some sort of server push manifest could work well, mapping between requested asset filenames and arrays of filenames to push. Google App Engine has taken this approach (see the example for “multi-file manifest format”).

My interest in this is tied to my development of a JS build tool. This tool can bundle JavaScript SPAs in a way that is H2-friendly, as well as providing a server push manifest. Since it is a simple mapping, it could be adapted to integrate with probably any API that you end up with.

In any case, would be very excited to see KeyCDN make this happen. If you’d like to discuss further, feel free to reach out!


#6

I would suggest using the preload directive in the HTTP response header. That way you already benefit from the fact that the browser starts requesting certain assets already at the beginning instead they have been requested after a CSS file calling them.

Link: <https://foobar.com/assets/styles.css>; rel=preload; as=style

This will circumvent the chicken-egg problem as this is also used for the server push scenario.

A pushed response is semantically equivalent to a server responding to a request and, similar to a preloaded response, is retained by the user agent and executed by the application when matched with another request initiated by the application. As such, from an application perspective, there is no difference between consuming a preload or a server push response.
https://www.w3.org/TR/preload/#server-push-http-2

Another important statement is the following. Clients might deny or limit server push, which needs to be considered when you create your concept how you want to deliver the assets to the browser.

Applications cannot rely on the availability and use of server push.

We are definitely working on this feature to make it available. Server push is an interesting approach to making a website faster but it requires more development and engineering effort to get it done right.


#7

@divmain @eva2000 We’ve just launched HTTP/2 support for all KeyCDN customers. You can check our latest blog post to learn more: https://www.keycdn.com/blog/http2-push/


#8

Status: The requested feature has been implemented.


#9