History and Future

History

HTTP/0.9 (1991)

The original protocol had no version number, no headers, and no status codes. A request was a single line:

GET /page.html

The server responded with raw HTML and closed the connection. That’s it. No content type, no error handling, no metadata.

HTTP/1.0 (1996)

HTTP/1.0 (RFC 1945) added the features we now consider essential:

• Headers — both request and response headers for metadata.
• Status codes — 200 OK, 404 Not Found, 500 Internal Server Error.
• Content types — the Content-Type header, enabling non-HTML responses.
• New methods — POST and HEAD alongside GET.

The major limitation: one request per TCP connection. Loading a page with 20 images meant 20 separate TCP connections, each with handshake overhead.

HTTP/1.1 (1997–2022)

HTTP/1.1 was a major leap that introduced:

• Persistent connections — reuse TCP connections across multiple requests.
• Host header — required in every request, enabling virtual hosting.
• Chunked transfer encoding — stream responses of unknown size.
• Content negotiation — Accept, Accept-Language, Accept-Encoding.
• Caching — Cache-Control, ETag, conditional requests.
• Range requests — partial content delivery for resumable downloads.
• Pipelining — send multiple requests without waiting (though rarely used in practice).

The specification was revised multiple times:

• RFC 2068 (1997) — initial specification.
• RFC 2616 (1999) — consolidated revision, the reference for 15+ years.
• RFC 7230–7235 (2014) — split into six focused documents for clarity.
• RFC 9110–9112 (2022) — current standard, separating semantics from wire format.

HTTP Today

HTTP/1.1

Still widely deployed and the dominant protocol for:

• Server-to-server communication behind load balancers.
• Reverse proxies and internal APIs.
• Environments where simplicity and debuggability matter.
• Legacy systems and embedded devices.

Its text-based format makes it uniquely accessible for debugging — you can literally read the bytes on the wire.

HTTP/2 (2015, RFC 9113)

HTTP/2 addressed HTTP/1.1’s performance limitations:

• Binary framing — messages are encoded in binary frames instead of text. More compact and less error-prone to parse.
• Multiplexing — multiple concurrent request/response exchanges on a single connection, eliminating head-of-line blocking at the HTTP layer.
• Header compression (HPACK) — compresses headers using a static table and dynamic indexing. Headers like Host, Accept, and User-Agent that repeat on every request are sent efficiently.
• Server push — the server can proactively send resources it knows the client will need. (Largely deprecated — Chrome removed support in 2022.)
• Stream prioritization — clients can indicate which resources are more important.

HTTP/2 keeps the same semantics (methods, status codes, headers) as HTTP/1.1 — it only changes how messages are framed on the wire. Most HTTP/2 deployments use TLS (the h2 protocol identifier negotiated via ALPN).

HTTP/3 (2022, RFC 9114)

HTTP/3 replaces TCP with QUIC, a UDP-based transport:

• No TCP head-of-line blocking — packet loss on one stream doesn’t block others. In HTTP/2 over TCP, a single lost packet stalls all streams.
• 0-RTT connection setup — QUIC combines the transport and TLS handshake into a single round-trip. Resumed connections can send data immediately (0-RTT).
• Connection migration — a QUIC connection survives network changes (e.g., switching from Wi-Fi to cellular) because it’s identified by a connection ID, not a source IP+port tuple.
• Built-in encryption — TLS 1.3 is mandatory and integrated into the transport layer.
• Header compression (QPACK) — similar to HPACK but designed for QUIC’s out-of-order delivery.

The Future

Active work in the IETF HTTP Working Group includes:

• WebTransport — bidirectional, multiplexed transport for web applications, built on HTTP/3. Enables use cases like game networking and live media that need both reliable and unreliable delivery.
• HTTP Datagrams (RFC 9297) — unreliable datagram delivery over HTTP connections. Enables latency-sensitive applications that can tolerate packet loss.
• MASQUE proxying — using HTTP CONNECT-UDP and CONNECT-IP for tunneling arbitrary IP and UDP traffic through HTTP proxies. Enables VPN-like functionality over HTTP infrastructure.
• Resumable uploads — standardizing the ability to pause and resume large file uploads (draft-ietf-httpbis-resumable-upload).
• Ongoing refinement of HTTP semantics, caching specifications, and security best practices.

Alternatives to HTTP

HTTP is not the only application-layer protocol. Depending on the use case, other protocols may be a better fit:

Learn More

Videos

• HTTP Crash Course & Explore — Traversy Media
• How HTTP Requests Work — LiveOverflow
• HTTP/1 to HTTP/2 to HTTP/3 — Hussein Nasser

Documentation

• MDN: An overview of HTTP — beginner-friendly reference.
• RFC 9110 — HTTP Semantics — the current specification for HTTP semantics.
• RFC 9112 — HTTP/1.1 — the current specification for HTTP/1.1 message syntax.
• RFC 9113 — HTTP/2 — the HTTP/2 specification.
• RFC 9114 — HTTP/3 — the HTTP/3 specification.
• IETF HTTP Working Group — active drafts, meeting notes, and mailing list.
• High Performance Browser Networking — Ilya Grigorik’s free online book covering HTTP, TLS, and networking performance.