The curious side-effects of HTTP 2 push promises

Sat, Jun 20, 2015 ❝Curious side-effects of HTTP 2 push promises❞

Contents

For a long time we’ve used the web in its standard incarnation: HTTP/1.1. A lot has changed on the internet, but the underlying protocol always stayed the same.

Recently, HTTP 2 (HTTP/2) was standardized. Large companies already migrated to using HTTP 2. Even as an experiment called Speedy (SPDY), there was very quickly a lot if interest in these improvements, as there were a number of wide-known drawbacks for which work arounds have been devised over the years. (Some of which are now obsolete, even harmful.)

Http 2 has a number of improvements that, frankly, were way over due. The improvements are in general improvements on the old protocol, but specifically there are a number of improvements geared towards increasing the performance of (the transport protocol for) websites.

I want to talk about one improvement in particular. This improvement is called “Push Promises”, also referred to as server pushes. They essentially provide a mechanism for the server to send you data before you ask for it. As you will understand, a web site will load even faster if you do not first have to ask for additional data. Push promises are announcements that the data is going to be sent, then following this “synthetic request” the server sends the actual data to the client. Once a client, for example your web browser, discovers that it wants to request this specific piece of data, it finds out that a matching push promise was already announced and thus the data is either already fully available, or at the very least already in transit. This saves both the request and transport time.

Apart from the obvious uses, there are curious applications of this:

1. Will we see selling of “premium” ads as priority push promises?
   “Premium” ads would be pushed first (and with highest priority - otherwise you could not guarantee first arrival) and we could virtually guarantee that the premium ad would be the first ad, or even the first image, the user will see on your website.
   Luckily, ads typically originate from the ad network’s own domain, if only to give the ad network more control over content. So we will probably not see this use case very soon. Of course, if the web browser of a user has ad blocking extensions enabled, then he might not see the ad anyways, even if it was pushed to the client.
2. What happens if the server pushes data to a user that turns out to be illegal?
   The user didn’t request the data, but still got it. The user’s web browser actively accepted it, as it was announced through this mechanism, even though it didn’t request it.
3. Side channel for acquiring content
   This mechanism could be used as a way to push otherwise unrequestable resources to a client. The pushed resources do not have to be referenced in any other resources, such as an HTML document.

Once HTTP 2 is in use at more websites, it would be interesting to see how much push promises are used. A good application of this could result in a client requesting a web page and receiving a web page + most relevant content referenced from that web page. As if you requested everything in one bundle. That would clearly result in improved performance. Incorrect use, on the other hand, would result in unnecessary downloads and consequently delays for other lower priority relevant data.

HTTP 2 leaves room for more intelligent web servers. Web servers that know the content they serve and intelligently select resources to push with each page request. Resources that are requested regularly - in general or per web page - can be pushed immediately. Interestingly, javascript and css files would probably make bad candidates. They are typically complete collections of code/styling and if received once, they can be cached and reused on the client side. On the other hand, it leaves more room for intelligent behaviour specific to the current context, such as the requested web page.