HTTP/2 Server Push: Difference between revisions

Revision as of 20:55, 30 March 2019

Revision as of 20:41, 1 April 2019

Line 23:

When the server wants to push a resource, it prepares a PUSH_PROMISE frame, architecting it in the best way possible to seduce the browser into using the pushed contents. Then the server annexes the PUSH_PROMISE frame to the response part of a normal, browser-initiated stream. However, the actual data for the pushed resource is sent in a fresh stream started by the server{{snd}} and thus with an even number.

The browser holds the pushed data in a temporary "quarantine" zone until it decides to use it. Later, every time the browser is going to make an actual request, it examines the contents of any received push promises to see if it is similar enough to the request it wants to make. However, the server need not wait until that moment to start sending data for the promised resource. After the PUSH_PROMISE frame has been sent on the browser-initiated stream, the server can send thatwhat would be response headers using a HEADERS frame in the new server-initiated stream, and later it can send the data of the resource using DATA frames. And at any point in time, the browser can interrupt any transfer by using RST_STREAM.

Here is how this would work in the previous example. If the server is HTTP/2 PUSH ready, when it receives a request to index.html it can forecast that requests to styles.css and script.js are following close in tail. So it issues push promises to get a bit ahead of events. Here is how things could look, in order of occurrence and making up the stream numbers: