HTTP/2 Server Push: Difference between revisions

Revision as of 20:50, 13 June 2023

Latest revision as of 13:29, 2 July 2025

(18 intermediate revisions by 15 users not shown)

Line 1:

{{Short description |WebOutdated web optimization protocol}}

{{use dmy dates|date=April 2022|cs1-dates=y}}

{{Multiple issues|

{{more citations needed |date=May 2016}}

{{tone |date=September 2017}}

}}

'''HTTP/2 Server Push''' is an optional<ref>{{Cite journal |date=May 2015 |title=Hypertext Transfer Protocol Version 2 (HTTP/2) |doi=10.17487/RFC7540 |url=https://www.rfc-editor.org/rfc/rfc7540 |url-status=live |quote=A client can request that server push be disabled|last1=Belshe |first1=M. |last2=Peon |first2=R. |last3=Thomson |first3=M. |editor-first1=M |editor-last1=Thomson |doi-access=free }}</ref> feature of the [[HTTP/2]] and [[HTTP/3]] [[Communication protocol|network protocols]] whichthat allows [[Server-side|servers]] to send resources to a [[Client–server model|client]] before the client requests them. Server Push is a performance technique aimed at reducing latency by loadingsending resources preemptively,to evena beforeclient thepreemptively clientbefore it knows they will be needed.<ref>{{Cite web |last=Staff |first=Ars |date=2015-02-18 |title=HTTP/2 finished, coming to browsers within weeks |url=https://arstechnica.com/information-technology/2015/02/http2-finished-coming-to-browsers-within-weeks/ |access-date=2023-01-12 |website=Ars Technica |language=en-us}}</ref> In practice, Server Push frequently results in wasted bandwidth because the server rarely knows which resources are already loaded by the client and transmits the same resource multiple times, resulting in slowdowns if the resources being pushed compete for bandwidth with resources whichthat were actually requested.<ref name=":0">{{Cite web |date=2020-11-11 |title=Intent to Remove: HTTP/2 and gQUIC server push |url=https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ?pli=1 |url-status=live |archive-url=https://web.archive.org/web/20211128080039/https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ?pli=1 |archive-date=2021-11-28 |access-date=2022-04-12 |website=[[Google Groups]] |language=en}}</ref>

HTTP/2 Server Push is not a notification mechanism from server to client. Instead, pushed resources are used by the client when it may have otherwise produced a request to get the resource anyway.<ref>{{Cite web |title=HTTP/2 server configurations |url=https://http2.co/http2-with-apache/ |url-status=live |archive-url=https://web.archive.org/web/20220327085843/https://http2.co/http2-with-apache/ |archive-date=2022-03-27 |access-date=2019-03-30 |website=HTTP/2 Space |language=en-US}}</ref><ref>{{cite IETF |title=Hypertext Transfer Protocol Version 2 (HTTP/2) |rfc=7540 |section=8.2 |sectionname=Server Push |page=60 |date=May 2015 |publisher=[[Internet Engineering Task Force]] |access-date=2015-05-06 |language=en-US |archive-url=https://web.archive.org/web/20220404104429/https://datatracker.ietf.org/doc/html/rfc7540 |archive-date=2022-04-04 |url-status=live}}</ref>

== Basic conceptHistory ==

On May 14, 2015, HTTP/2 was standardized by {{IETF RFC|7540}}, ratified as a Proposed Standard. The document includes section 8.2 entitled "Server Push" which introduced the concept to the protocol as an optional extension. [[Google Chrome]] 40 became the first browser supporting the final standardized HTTP/2 version, including the optional Server Push.<ref>{{Cite web |last= |first= |date=2015-02-10 |title=Google announces SPDY's coming demise as HTTP/2 approaches |url=https://arstechnica.com/information-technology/2015/02/google-announces-spdys-coming-demise-as-http2-approaches/ |access-date=2023-07-30 |website=Ars Technica |language=en-us}}</ref>

For example, in the case of a website with three resources: index.html, styles.css and script.js, when a user, through their browser, connects to Wikipedia webserver to get the home page, they automatically retrieve index.html. As the browser parses the [[HTML]] text in index.html, it finds instructions that will require styles.css and script.js. At that point, the browser will issue requests to get these other two files. To assemble the complete webpage, the browser will stack such requests as it gradually discovers the site's composition.

In February 2018, [[Nginx]] 1.13.9 was released with optional support for HTTP/2 Server Push.<ref name=":1" />

With HTTP/2 Push, the server can take the initiative by having rules that trigger content to be sent even before it is requested. In this example scenario, the server knows that anyone requesting index.html will need styles.css and script.js, so it can push them to the client immediately without waiting for the client to request them. If done correctly, by the time the browser finishes parsing index.html, the transfer of styles.css and script.js would have already started, or even completed, removing the latency of having to request these and wait for them to arrive.

In November 2020, [[Google]] announced its intent to remove Server Push from Google Chrome implementation of HTTP/2 and [[QUIC|gQUIC]] (which later evolved into HTTP/3).<ref>{{Cite web |last=Lassey |first=Brad |date=2020-11-12 |title=Intent to Remove: HTTP/2 and gQUIC server push |url=https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ |access-date=2023-11-20 |website=Blink mailing list}}</ref>

== How HTTP/2 PUSH works at a protocol level ==

Push works over HTTP/2, which at its core is a frames protocol, meaning that information is exchanged in groups of bytes called frames. Additionally, frames are part of streams, and streams are identified by a number. The stream number is present in each frame as a binary field. Streams allow matching requests to responses, e.g. the response to request GET /index.html at stream 3 must also be at stream 3.

In October 2022, Google announced their intent to remove Server Push from Google Chrome, citing the poor performance of the extension in practice, lack of use and better alternatives. Chrome 106 became the first release disabling Server Push by default.<ref name=":2">{{Cite web |date=2022-08-18 |title=Removing HTTP/2 Server Push from Chrome |url=https://developer.chrome.com/blog/removing-push/ |access-date=2023-07-30 |website=Chrome Developers |language=en}}</ref>

There are different types of frames, and each has a different function. HTTP/2 has only a few of these types, and we don't need all of them to explain the basics. Here are the ones interesting for this description:

On October 29, 2024, [[Mozilla Corporation|Mozilla]] released [[Firefox]] 132, which removed HTTP/2 Server Push support due to "compatibility issues with various sites".<ref>{{Cite web |title=Firefox 132.0, See All New Features, Updates and Fixes |url=https://www.mozilla.org/en-US/firefox/132.0/releasenotes/ |access-date=2024-10-29 |website=Mozilla |language=en}}</ref>

* HEADERS frame. As its name implies, this type of frame carries HTTP headers. When sent by the browser to the server, it signals that a request is being made. When sent by the server to the browser, it signals that a response to a previous request or push promise is being sent.

* PUSH_PROMISE frame. This frame is sent by the server to the browser to start pushing a resource. It also contains HTTP headers. However, the kind of headers present in a PUSH_PROMISE frame are headers that would normally be present in a request. This is different from the response headers that a server would normally send. The request URL, for example, is present in the PUSH_PROMISE frame as the HTTP/2-specific :path pseudo-header, as is the :authority pseudo-header to indicate a host. Other headers that may be present in a PUSH_PROMISE and that some browsers use are cache headers, for example, if-none-match.

* DATA frames. These frames are sent in either direction to carry the actual content of a resource or the contents that the browser POSTs or PUTs to the server.

* RST_STREAM frames. These frames serve many purposes. One of them is having the browser signal to the server that a pushed stream is not needed.

== Protocol ==

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{{thinsp|—}}and thus with an even number.

Unlike [[HTTP|HTTP/1.1]], HTTP/2 can multiplex multiple streams on one TCP connection. Server Push allows the server to open new streams by sending PUSH_PROMISE frames, in order to send the client resources it expects will be needed. A PUSH_PROMISE frame is similar to a GET request, but sent by the server. A client may choose to reject the push by sending an RST_STREAM frame, for example, if it already has the resource cached; if it does not, it will store the pushed data in a cache associated with the connection which will be consulted before a request is sent down that connection. Clients can also request that servers not send server pushes using a SETTINGS frame. The specification itself does not specify how servers choose what to push: a web server might send pushes to clients only on their first visit, to avoid redundantly sending cached resources.<ref>{{Cite web |date=2022-03-17 |title=HTTP/1.1 vs HTTP/2: What's the Difference? |url=https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference |access-date=2023-11-20 |website=DigitalOcean |language=en}}</ref><ref>{{Cite web |date=2018-02-20 |title=Introducing HTTP/2 Server Push with NGINX 1.13.9 |url=https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/ |access-date=2023-11-20 |website=Nginx |language=en}}</ref><ref>{{Cite web |date=2016-04-28 |title=Announcing Support for HTTP/2 Server Push |url=https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ |access-date=2023-11-20}}</ref>

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 what 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:

* Server receives HEADERS frame asking for index.html in stream 3, and it can forecast the need for styles.css and script.js.

* Server sends a PUSH_PROMISE for styles.css and a PUSH_PROMISE for script.js, again in stream 3. These frames are roughly equivalent to a browser's request.

* Server sends a HEADERS frame in stream 3 for responding to the request for index.html.

* Server sends DATA frame(s) with the contents of index.html, still in stream 3.

* Server sends HEADERS frame for the response to styles.css in stream 4{{thinsp|—}}notice the even stream number{{thinsp|—}}and then for the response to script.js in stream 6.

* Server sends DATA frames for the contents of styles.css and script.js, using their respective stream numbers.

Push promises are sent as early as possible so that the browser will have them well ahead of any discoveries. Notice that HTTP headers (specifically Link with the 'preload' keyword<ref>{{Cite web |date=2022-03-29 |title=Preload |url=https://w3c.github.io/preload/ |url-status=live |archive-url=https://web.archive.org/web/20220405203114/https://w3c.github.io/preload/ |archive-date=2022-04-05 |access-date=2022-04-12 |website=[[GitHub]] |publisher=[[World Wide Web Consortium]] |language=en-US}}</ref>) can reveal URLs that the browser needs to fetch, and an eager browser would start asking for the resources upon seeing those headers. Therefore, push promises are best sent before even the response headers of the stream where they are attached.<ref name="shimmercat">{{Cite web |date=2018-04-25 |title=A closer look to HTTP/2 Push |url=https://www.shimmercat.com/blog/whats-push/ |url-status=live |archive-url=https://web.archive.org/web/20210304192055/https://www.shimmercat.com/blog/whats-push/ |archive-date=2021-03-04 |website=[[ShimmerCat]]}}</ref>

== Implementations ==

{| class="wikitable"

HTTP/2 Server push was implemented in the [[Nginx]] web server in version 1.13.9 in February 2018.<ref>{{Cite web |date=2018-12-04 |title=Changes with nginx 1.14.2 |url=https://nginx.org/en/CHANGES-1.14 |url-status=live |archive-url=https://web.archive.org/web/20220407053209/https://nginx.org/en/CHANGES-1.14 |archive-date=2022-04-07 |website=[[Nginx]] |language=en-US}}</ref> Support was removed in version 1.25.1 in June 2023.

|+

!Software

According to the [[Google Chrome]] team, Server Push in HTTP/2 and gQUIC is rarely used, and the pushed resources are more often unused than used. They have proposed to remove the feature from Chrome and Chromium.<ref name=":0" />

!

!First supporting version

!Last supporting version

|-

|[[Nginx]]

|Server

HTTP/2 Server push was implemented in the [[Nginx]] web server in version |1.13.9 in (February 2018.)<ref name=":1">{{Cite web |date=2018-12-04 |title=Changes with nginx 1.14.2 |url=https://nginx.org/en/CHANGES-1.14 |url-status=live |archive-url=https://web.archive.org/web/20220407053209/https://nginx.org/en/CHANGES-1.14 |archive-date=2022-04-07 |website=[[Nginx]] |language=en-US}}</ref> Support was removed in version 1.25.1 in June 2023.

|1.25.1 (June 2023)<ref>{{Cite web |date=13 June 2023 |title=Changes with nginx 1.25.1 |url=https://nginx.org/en/CHANGES |access-date=12 July 2023 |website=[[Nginx]]}}</ref>

|-

|[[LiteSpeed Web Server|LiteSpeed]]

|Server

|5.2

|Still supported, but deprecated<ref>{{Cite web |title=Page Optimization |url=https://docs.litespeedtech.com/lscache/lscwp/pageopt/#css-http2-push |access-date=2023-07-21 |website=LiteSpeed Documentation}}</ref>{{Better source needed|reason=This is a primary source, no clear mention of deprecation/removal timeline ([[WP:NOTRS]]).|date=July 2023}}

|-

|[[Google Chrome]]

|Client

|40 (May 2015)

|106 (September 2022)<ref name=":0" /><ref name=":2" /><ref>{{Cite web |date=2022-10-31 |title=Remove HTTP/2 push |url=https://chromestatus.com/feature/6302414934114304 |access-date=2023-07-12 |website=chromestatus.com}}</ref>

|-

|[[Firefox]]

|Client

|?

|131.0 Beta 9<ref>{{Cite web |title=Intent to unship: HTTP/2 Push |url=https://groups.google.com/a/mozilla.org/g/dev-platform/c/vU9hJg343U8/m/4cZsHz7TAQAJ |access-date=2024-09-06 |website=groups.google.com}}</ref><ref>{{Cite web |title=Firefox Beta 132.0beta, See All New Features, Updates and Fixes |url=https://www.mozilla.org/en-US/firefox/132.0beta/releasenotes/?utm_source=firefox-browser&utm_medium=firefox-desktop&utm_campaign=about-dialog |access-date=2024-10-01 |website=Mozilla |language=en}}</ref>

}|}

== References ==