Version 2 of the Hypertext Transfer Protocol (HTTP/2), published in 2015, introduced a Server Push protocol primitive, offering the possibility of improving user-perceived web page performance through the unsolicited delivery of additional dependent resources by a web server in response to an initial request from a client. Analysis of deployments in the wild has shown actual performance gains to vary greatly, and even reduced performance in some cases.

 

Current web browsers hold pushed resources in a so-called “Push Cache”, where they exist in effective purgatory until explicitly requested. Server Push is, in essence, hidden from the Web Application. We contend that the failure to expose Server Push events to the Web Application layer has impeded the realisation of promised performance improvements. Furthermore, hiding Server Push restricts a new set of use cases that would benefit from a reactive approach to web-oriented HTTP delivery of resources, in particular unidirectional flows such as long-lived bulk data delivery and low-latency delivery.

 

We have designed and prototyped a candidate Server Push API that could be used to address reactive use cases. Our proof of concept combines this API with a W3C Service Worker to power a novel MPEG-DASH video streaming web application. Media content is pushed to this application using BBC R&D’s experimental IP multicast profile of HTTP/QUIC, the goals of which are scalability, reachability, simplicity, seamlessness and commonality across unicast and multicast delivery modes.

 

We are now looking to engage with the web community, particularly browser vendors, on how to fill the Server Push API gap natively for all.