How HTTP works: from HTTP/1.1 to HTTP/3

The basic principle: request and response

All HTTP communication consists of a request from the client and a response from the server. HTTP is stateless: each request stands on its own, and the server doesn’t remember by itself who you are from one request to the next. That’s why cookies exist: they let the browser send an ID with every request, so the server can recognize a login or a cart.

A simple request looks like this:

GET /products/coffee HTTP/1.1
Host: mystore.com
Accept: text/html
Accept-Language: en-US

And the server’s response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=300

(the HTML page itself)

Methods

The method says what the client wants:

• GET fetches a resource, such as a page or an image. It doesn’t change anything on the server.
• POST sends data, such as a form or an order.
• PUT and PATCH replace or update a resource, usually in APIs.
• DELETE deletes a resource.
• HEAD fetches only the headers, not the content, and OPTIONS asks what the server allows.

Two properties of the methods matter in practice. GET, HEAD and OPTIONS are safe: they mustn’t change anything, which is why browsers, caches and search engines can call them without asking. PUT and DELETE are idempotent: if the same request is sent twice, the result is the same as after one. POST isn’t, which is why the browser warns you before resending a form, and why an integration has to be careful not to create an order twice when a call is retried after a timeout.

Status codes

Group	Meaning	Typical examples
2xx	It worked	200 OK, 201 Created, 204 No Content
3xx	Redirect, or use your copy	301 moved permanently, 302 and 307 moved temporarily, 304 Not Modified
4xx	Client error	400 bad request, 401 login required, 403 forbidden, 404 not found, 429 too many requests
5xx	Server error	500 internal error, 502 and 504 errors in an intermediate server, 503 temporarily unavailable

For SEO, the difference between 301 and 302 matters: a 301 tells search engines the page has moved permanently, so the new address takes over the ranking.

Headers and caching

Headers carry everything that isn’t the content itself: content type, language, cookies, compression and caching. The most important for speed are the caching headers. Cache-Control tells browsers and CDNs how long a response may be reused, and with ETag or Last-Modified, the browser can ask whether its copy is still valid. If it is, the server simply replies 304 Not Modified without sending the content again.

The response headers you’ll run into most often as a website owner:

Header	What it does
Cache-Control	How long and by whom the response may be reused
Content-Encoding	Whether the content is compressed, usually with gzip or Brotli (br)
Location	The new address in a redirect
Set-Cookie	Stores a cookie in the browser, for a login or a cart, for example
Strict-Transport-Security	Makes the browser always use HTTPS for the domain (HSTS)
Vary	Tells caches that the response depends on, for example, language or compression

See it for yourself

You can see all of this on your own site. In the browser’s developer tools, the Network tab shows every request with its method, status code, headers and protocol version. From a terminal, curl -I fetches only the headers:

$ curl -I https://yourstore.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=300
content-encoding: br

If you get a 301 or 302, the new address is in location, and with curl -IL you follow the whole chain, which is the quickest way to find redirects that loop or take a detour.

The history of HTTP

HTTP was developed by Tim Berners-Lee at CERN around 1990, together with HTML and the first browser. The first version, later called HTTP/0.9, could do only one thing: fetch an HTML document. Since then, the protocol has been extended in clear steps:

Version	Year	Main new feature
HTTP/0.9	1991	Only GET and only HTML
HTTP/1.0	1996	Headers, status codes and file types other than HTML
HTTP/1.1	1997	Persistent connections and the Host header
HTTP/2	2015	Binary format and many requests over one connection
HTTP/3	2022	Runs over QUIC instead of TCP

Every new version has kept the same basic model of methods, status codes and headers. What has changed is how messages are packaged and transported. The protocols are developed in the IETF and described in RFCs, and in 2022 the whole HTTP family was brought together and updated in a new series of specifications. If you want to know more about how the internet’s protocols came about, read about the history of network protocols.

HTTP/1.1

HTTP/1.1 was the standard for almost 20 years and is still in use. Messages are plain text, as in the examples above, and they’re sent over a TCP/IP connection. Compared with HTTP/1.0, the same connection could now be reused for several requests instead of opening a new one each time, and the new Host header made it possible to have many websites on the same IP address, which is the basis of almost all modern hosting. The server could also start sending a response before it knew the total size, and caching got much better with Cache-Control and conditional requests.

The big limitation is that each connection can only handle one request at a time, and a slow response blocks all the ones after it (head-of-line blocking). Browsers therefore open several connections in parallel to each server, and developers learned to bundle files, create sprites and spread files across several domains to get around it. Much of that is unnecessary or even harmful with HTTP/2.

HTTP/2

HTTP/2 built on Google’s experimental SPDY protocol and changed how data is sent, without changing the meaning of methods, headers and status codes. Messages are split into small binary frames, and many requests and responses can be sent at the same time over one connection as separate streams. This is called multiplexing, and it removes the need for several parallel connections. At the same time, headers are compressed with HPACK, so information repeated on every request, like cookies, is only sent once.

Not every new feature lasted. Server push, where the server could send files before the browser asked for them, rarely helped and has been removed from the major browsers. And HTTP/2 only solved the queueing problem in HTTP, not in TCP: all streams share one TCP connection, so if one packet is lost, they all wait. On poor connections, HTTP/2 can therefore be as slow as HTTP/1.1. In practice, HTTP/2 is only used over HTTPS, because browsers require it.

HTTP/3 and QUIC

HTTP/3 solves the last queueing problem by replacing TCP with QUIC, a transport protocol on top of UDP that was developed at Google and standardized in the IETF in 2021. QUIC knows about the streams itself, so a lost packet only delays the stream it belongs to. TLS 1.3 is built in, so connection and encryption are set up in one round trip instead of two or three, and on repeat visits data can be sent right away.

A QUIC connection also isn’t identified by IP address and port, but by an ID, so it can survive a phone switching from Wi-Fi to mobile data. Header compression is adapted as QPACK, because packets can arrive in any order. The browser discovers that a server supports HTTP/3 through an Alt-Svc header or an HTTPS record in DNS, and falls back to HTTP/2 if UDP can’t get through. What it means in practice, you can read in what HTTP/3 means for your store’s speed.

The versions compared

	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC over UDP
Format	Text	Binary	Binary
Requests per connection	One at a time	Many at once	Many at once
Queueing on packet loss	Yes	Yes, at the TCP level	Only in the affected stream
Encryption	Optional (TLS)	Required in practice (TLS)	Built in (TLS 1.3)
Header compression	No	HPACK	QPACK

HTTP and HTTPS

HTTPS isn’t a separate protocol, but HTTP sent through an encrypted TLS connection. Everything in this guide applies to HTTPS too. Today all traffic should be encrypted, and HTTP/2 and HTTP/3 require it in practice. Read more in our guide to HTTPS and TLS.

Frequently asked questions

Which HTTP version does my site use?

Open the browser’s developer tools, go to the Network tab, and turn on the Protocol column. It shows http/1.1, h2 or h3 for each file.

Should I still bundle my CSS and JavaScript files?

Not to the same extent as with HTTP/1.1. With HTTP/2 and HTTP/3, many small files can be fetched in parallel, and smaller files can be cached individually. Minification and avoiding unnecessary files still make sense.

Is HTTP/1.1 outdated?

No, it’s still used in many places, including between servers and in many APIs. But toward browsers, a modern website should offer HTTP/2 and ideally HTTP/3.