Updated HTTP specifications: new HTTP/3 and updated HTTP/1.1 and HTTP/2


Literally everything that we do on the Web today, and the vast majority of what happens in the API space, is based on the Hypertext Transfer Protocol (HTTP). It has been around since the Web was created in 1989. HTTP quickly went from HTTP/1.0 to HTTP/1.1 (in 1997) which remained the latest version for many years. In 2015, HTTP/2 entered the picture, improving HTTP performance by multiplexing requests over one TCP connection. Finally, this month (June 2022), the Internet Engineering Task Force (IETF) published the latest version: HTTP/3.

What’s different about HTTP/3?

HTTP/3 is another major upgrade that further improves HTTP performance by replacing the traditional TCP foundation with a combination of UDP and QUIC.

Per RFC 9114: “The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.” As itnews explains, this improves load times by minimizing the handshaking needed to establish a connection, which is particularly important on mobile networks.

“The QUIC transport protocol incorporates stream multiplexing and per-stream flow control, similar to that provided by the HTTP/2 framing layer,” RFC 9114 continues. “By providing reliability at the stream level and congestion control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping. QUIC also incorporates TLS 1.3 ([TLS]) at the transport layer, offering comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open ([TFO]).”

Cybersecurity journalist John Leyden summarizes HTTP/3 this way: practically speaking, it reduces the latency of poor or lossy internet connections. And as Cloudflare points out, the new standard also incorporates an important security feature: because of how QUIC approaches handshakes, HTTP/3 essentially provides “encryption by default.”

(For a deeper dive into what HTTP/3 is and what it means for APIs, check out my discussion with network protocol and Web performance expert Robin Marx.)

Both HTTP/1.1 and HTTP/2 are still hugely relevant and will be used for a long time to come. What we have here is a new set of specifications covering both what information is exchanged (HTTP), and how it’s exchanged (HTTP/1.1, HTTP/2 and HTTP/3).

Without going into too much technical detail, it is still very interesting to look at how HTTP evolved over the years. The publication of the latest specifications is a great opportunity to do that.

A brief history of HTTP

HTTP/1.0 was published as RFC 1945 in May 1996. Work on a new version was already underway, but this documented the current and stable practice at that point.

HTTP/1.1 was first published in January 1997 as RFC 2068. The biggest change over HTTP/1.0 is that it introduced persistent connections and pipelining. It therefore used TCP/IP much more efficiently, and since Web pages used more and more resources (HTML, images, CSS, scripts, …), this improvement helped immensely to make the Web faster.

In June 1999, RFC 2616 was published, which improved the specification of HTTP/1.1, but was not a different version of HTTP. RFC 2616 remained the reference for 15 years.

Because 2616 was big and hard to read, and because work had started on a new version of HTTP, in June 2014 a series of RFCs was published which replaced RFC 2616. This series still standardized HTTP/1.1 and had RFCs 7230-7035 in it. RFC 7231 specifically was a “Semantics” document which talked about what HTTP concepts such as request methods, header fields, and status codes mean, without talking about their specific representation on the wire in HTTP/1.1.

Based on the HTTP semantics it was now possible to create new wire formats, which happened with the publication of HTTP/2 as RFC 7540 in May 2015. This protocol was originally known as SPDY and introduced binary representations and the multiplexing of interactions on one TCP connection, creating significant performance enhancements over HTTP/1.1.

In June 2022 a new series of RFCs was published, RFC 9110 to 9114. RFC 9110 defines the HTTP semantics and now is the reference for the concepts of HTTP. RFC 9112 is an updated version of HTTP/1.1. RFC 9113 is an updated version of HTTP/2.

RFC 9114 is a new version of HTTP, HTTP/3, which makes further performance improvements by replacing TCP with a different transport protocol: It uses UDP and then a relatively new protocol called QUIC which makes data transfers of independent streams more efficient.

What to expect next

It is likely that the RFC 9110 to 9114 series of documents will now remain stable for many years. A lot of work went into improving prior documents and aligning all three wire variants of HTTP. The Web now can transition from old HTTP/1.1 to more modern but still TCP-based HTTP/2, and further to the UDP/QUIC based HTTP/3.

This transition will take a while (although unofficial adoption has already been underway since late 2019), and during this transition period these latest documents will be the ones that define how the Web works.

If you’re interested in more details of HTTP’s evolution over the years, check out my discussion with Web expert Mike Amundsen. We take you on a journey from the very first specifications to the latest ones.

If you liked this video, why don’t you check out Erik’s YouTube channel for more “Getting APIs to Work” content?

Previous articleShifting gears in the used cars industry
Next articleDemonstrating an industry first with the FDX 5.0 API in action at FinovateSpring 2022 
Digital Catalyst, Erik works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions for using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books. He is a frequent speaker at global API events and contributes to standardization activities to help improve the way APIs are designed, managed, and used."


Please enter your comment!
Please enter your name here