HTTP/2 Server Push

Last updated

HTTP/2 Server Push is an optional [1] feature of the HTTP/2 and HTTP/3 network protocols that allows servers to send resources to a client before the client requests them. Server Push is a performance technique aimed at reducing latency by sending resources to a client preemptively before it knows they will be needed. [2] 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 that were requested. [3]

Contents

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. [4] [5]

History

On May 14, 2015, HTTP/2 was standardized by 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. [6]

In February 2018, Nginx 1.13.9 was released with optional support for HTTP/2 Server Push. [7]

In November 2020, Google announced its intent to remove Server Push from Google Chrome implementation of HTTP/2 and gQUIC (which later evolved into HTTP/3). [8]

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. [9]

On October 29, 2024, Mozilla released Firefox 132, which removed HTTP/2 Server Push support due to "compatibility issues with various sites". [10]

Protocol

Unlike 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. [11] [12] [13]

Implementations

SoftwareFirst supporting versionLast supporting version
Nginx Server1.13.9 (February 2018) [7] 1.25.1 (June 2023) [14]
LiteSpeed Server5.2Still supported, but deprecated [15] [ better source needed ]
Google Chrome Client40 (May 2015)106 (September 2022) [3] [9] [16]
Firefox Client?131.0 Beta 9 [17] [18]

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

<span class="mw-page-title-main">Web server</span> Computer software that distributes web pages

A web server is computer software and underlying hardware that accepts requests via HTTP or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.

The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a plain-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).

In computing, the User-Agent header is an HTTP header intended to identify the user agent responsible for making a given HTTP request. Whereas the character sequence User-Agent comprises the name of the header itself, the header value that a given user agent uses to identify itself is colloquially known as its user agent string. The user agent for the operator of a computer used to access the Web has encoded within the rules that govern its behavior the knowledge of how to negotiate its half of a request-response transaction; the user agent thus plays the role of the client in a client–server system. Often considered useful in networks is the ability to identify and distinguish the software facilitating a network session. For this reason, the User-Agent HTTP header exists to identify the client software to the responding server.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<span class="mw-page-title-main">HTTP pipelining</span> Computer communication technique

HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining.

Push technology, also known as server Push, refers to a communication method, where the communication is initiated by a server rather than a client. This approach is different from the "pull" method where the communication is initiated by a client.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

HTTP Live Streaming is an HTTP-based adaptive bitrate streaming communications protocol developed by Apple Inc. and released in 2009. Support for the protocol is widespread in media players, web browsers, mobile devices, and streaming media servers. As of 2022, an annual video industry survey has consistently found it to be the most popular streaming format.

SPDY is an obsolete open-specification communication protocol developed for transporting web content. SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

Web performance refers to the speed in which web pages are downloaded and displayed on the user's web browser. Web performance optimization (WPO), or website optimization is the field of knowledge about increasing web performance.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The initial HTTP/2 specification was published as RFC 7540 on May 14, 2015.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google. It was first implemented and deployed in 2012 and was publicly announced in 2013 as experimentation broadened. It was also described at an IETF meeting. The Chrome web browser, Microsoft Edge, Firefox, and Safari all support it. In Chrome, QUIC is used by more than half of all connections to Google's servers.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States. In May 2020, Chrome switched to DNS over HTTPS by default.

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP, HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP.

Client Hints are a set of HTTP Header fields and a JavaScript web application programming interface (API) for proactive content negotiation in the Hypertext Transfer Protocol (HTTP). The client can choose to advertise information about itself through these fields so that the server can then determine which resources should be included in its responses.

References

  1. Belshe, M.; Peon, R.; Thomson, M. (May 2015). Thomson, M (ed.). "Hypertext Transfer Protocol Version 2 (HTTP/2)". doi: 10.17487/RFC7540 . A client can request that server push be disabled{{cite journal}}: Cite journal requires |journal= (help)
  2. Staff, Ars (2015-02-18). "HTTP/2 finished, coming to browsers within weeks". Ars Technica. Retrieved 2023-01-12.
  3. 1 2 "Intent to Remove: HTTP/2 and gQUIC server push". Google Groups . 2020-11-11. Archived from the original on 2021-11-28. Retrieved 2022-04-12.
  4. "HTTP/2 server configurations". HTTP/2 Space. Archived from the original on 2022-03-27. Retrieved 2019-03-30.
  5. "Server Push". Hypertext Transfer Protocol Version 2 (HTTP/2). Internet Engineering Task Force. May 2015. p. 60. sec. 8.2. doi: 10.17487/RFC7540 . RFC 7540. Archived from the original on 2022-04-04. Retrieved 2015-05-06.
  6. "Google announces SPDY's coming demise as HTTP/2 approaches". Ars Technica. 2015-02-10. Retrieved 2023-07-30.
  7. 1 2 "Changes with nginx 1.14.2". Nginx . 2018-12-04. Archived from the original on 2022-04-07.
  8. Lassey, Brad (2020-11-12). "Intent to Remove: HTTP/2 and gQUIC server push". Blink mailing list. Retrieved 2023-11-20.
  9. 1 2 "Removing HTTP/2 Server Push from Chrome". Chrome Developers. 2022-08-18. Retrieved 2023-07-30.
  10. "Firefox 132.0, See All New Features, Updates and Fixes". Mozilla. Retrieved 2024-10-29.
  11. "HTTP/1.1 vs HTTP/2: What's the Difference?". DigitalOcean. 2022-03-17. Retrieved 2023-11-20.
  12. "Introducing HTTP/2 Server Push with NGINX 1.13.9". Nginx. 2018-02-20. Retrieved 2023-11-20.
  13. "Announcing Support for HTTP/2 Server Push". 2016-04-28. Retrieved 2023-11-20.
  14. "Changes with nginx 1.25.1". Nginx . 2023-06-13. Retrieved 2023-07-12.
  15. "Page Optimization". LiteSpeed Documentation. Retrieved 2023-07-21.
  16. "Remove HTTP/2 push". chromestatus.com. 2022-10-31. Retrieved 2023-07-12.
  17. "Intent to unship: HTTP/2 Push". groups.google.com. Retrieved 2024-09-06.
  18. "Firefox Beta 132.0beta, See All New Features, Updates and Fixes". Mozilla. Retrieved 2024-10-01.