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.

This paper explores Server Push from the perspective of Web Application logic implemented using JavaScript and the Web Platform. 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.

In this paper we describe a candidate Server Push API design that could be used to address reactive use cases. We describe a prototype that combines Server Push and Service Worker to power a novel MPEG-DASH video streaming Web Application, with media content delivered using BBC R&D’s experimental IP multicast profile of HTTP over QUIC. The goals of this are scalability, applicability to web-based clients, reduced operational costs, and commonality and seamless transition between unicast and multicast delivery modes. We show that the design achieves these goals and is generally applicable to a variety of long-lived unidirectional HTTP flows.