Archit Sharma

Posted on Oct 25

The History of HTTP

#http #networking #webdev #beginners

HTTP (HyperText Transfer Protocol) is a protocol used for fetching resources such as HTML documents. Its primary function is to enable a conversation between a client (like a web browser) and a server (where a website is hosted).

In this article, we will discuss how the World Wide Web was invented and how HTTP evolved from HTTP/0.9 to modern-day HTTP/3.

How the World Wide Web Was Invented

Tim Berners-Lee wrote a proposal to build a hypertext system over the internet in 1989, while working at CERN.

It had four fundamental pieces, all completed by the end of 1990:

HyperText Markup Language (HTML) - provide a textual format for hypertext documents.
HyperText Transfer Protocol (HTTP) - protocol to exchange these documents.
First Web Browser (WorldWideWeb) - a client to display these documents.
Early version of httpd - a server to give access to the document.

On August 6, 1991, Tim Berners-Lee posted the first ever web page. This date is now considered the official start of the World Wide Web as a public project.
You can still visit a restored version of it here: http://info.cern.ch/hypertext/WWW/TheProject.html

The HTTP protocol used in those early days was later named HTTP/0.9 and is sometimes called the one-line protocol.

HTTP/0.9

The first version of HTTP had no version number, but later it was called HTTP/0.9. It was a very simple protocol.
The Request message consisted of a single line, which began with the method (only GET was available) followed by the path to the resource. This is why its also known as the one-line protocol.

GET /my-page.html

The Response message only consisted of the file itself.

<html>
  An text-only web page
</html>

There were no HTTP headers and no status or error codes.

HTTP/1.0

Despite its limitations, HTTP/0.9 was rapidly enhanced by browsers and servers.
HTTP/1.0 introduced numerous improvements:

The version number, such as HTTP/1.0, was included directly in the request line.
By introducing HTTP headers for both requests and responses, the protocol gained the ability to carry metadata, making it very flexible and extensible.
Support for non-HTML content (like images, PDFs etc.) was made possible through the implementation of the Content-Type header.
A status code line was sent at the beginning of a response.

A typical request and response looked like this:

GET /page.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
Hello World
  <IMG SRC="/image.gif">
</HTML>

In the early days of the web (1991-1995), there was no official rulebook for new features. Developers would invent a new feature and wait to see if other browser and server developers adopted it. If others started using it, it became a de facto standard. If not, it would be abandoned.
To solve this issue, an informational document describing common practices was published in November 1996. This was known as RFC 1945 and defined HTTP/1.0.

HTTP/1.1

Just a few months after HTTP/1.0 (RFC 1945), the first standardized version of HTTP, HTTP/1.1, was published in early 1997.
HTTP/1.1 introduced major improvements:

Persistent Connections - a single TCP connection could be kept open and reused for multiple requests and responses, eliminating the significant overhead of repeatedly establishing connections.
Pipelining - a browser could send several requests back-to-back without waiting for the first response to arrive, reducing the delay (latency) in communication. (In practice, pipelining was difficult to implement correctly and was eventually superseded in HTTP/2).
Additional Cache Headers - It introduced much more powerful headers for controlling caches (both browser caches and proxy caches).
Chunked Responses - The server could send the response in pieces, or "chunks." It would send a Transfer-Encoding: chunked header and then stream the data in smaller parts, each with its own size indicator.
HOST Header - introduced the ability to host different domains from the same IP address.
Content Negotiation - a client and a server could now agree on which content to exchange.

HTTP/1.1 was first published as RFC 2068 (The Proposed Standard) in January 1997.
HTTP/1.1 protocol was refined over two revisions, RFC 2616 published in June 1999 and RFC 7230-RFC 7235 published in June 2014 before the release of HTTP/2.
The HTTP/1.1 standard (RFC 2616) remained stable for over 15 years.
In 2022, HTTP/1.1 was updated again with RFC 9110 & RFC 9112.

In 1994, Netscape created SSL (later standardized as TLS) to encrypt web traffic. This was initially for e-commerce security, but became essential for the entire web as it evolved from an academic network to a space where privacy and data protection were critical for all websites and applications.

The web was originally meant to be editable. WebDAV (with CalDAV/CardDAV) enabled this but required special server support.

REST (2000) became more popular by using standard HTTP methods on specific URLs, allowing any website to create its own API without browser updates. The trade-off was that each REST API was custom, unlike WebDAV's standardization.

HTTP and web security (same-origin policy) were developed separately. Over time, new HTTP headers were created to safely lift some security restrictions:

CORS - Allows controlled cross-origin requests
Content Security Policy (CSP) - Prevents certain types of attacks
Other headers like Do Not Track (DNT), X-Frame-Options, etc., were added for specific security and privacy needs

HTTP/2

Over the years, websites started using more videos, images, and complex scripts to make pages interactive. Websites sent more data and made more requests, which overwhelmed HTTP/1.1 and made it inefficient.
To address this issue, Google developed and deployed SPDY, an experimental protocol, in the early 2010s. Developers widely adopted Google's SPDY protocol because it made websites faster and more efficient. Its success directly led to the creation of the official HTTP/2 standard.

Here are the main ways HTTP/2 differs from HTTP/1.1:

Binary Protocol - HTTP/2 used binary instead of plain text which is much harder for humans to read, but computers can process binary data much faster and more efficiently.
Multiplexing - Parallel requests can be made over the same TCP connection.
Header Compression - It uses a smart technique (HPACK) that eliminates sending duplicate header fields, drastically reducing the amount of data that needs to be sent.

HTTP/2 standardized in May 2015 with RFC 7540 and RFC 7541.
HTTP/2 saw a rapid adoption because it didn't require changes to websites and applications. To use it, only an up-to-date server that communicated with a recent browser was necessary.

HTTP's extensibility still drives new features, notably these 2016 extensions:

Alt-Svc (Alternative Service) - enables smarter CDN caching because the browser can seamlessly switch to the faster location without changing the original resource's identity.
Cookie Security Prefixes - It guarantees that a "secure" cookie is truly secure from the moment it's created.
Client Hints - allows your browser to proactively tell the server about its capabilities and constraints.

HTTP/3

While HTTP/3 keeps the request/response semantics of HTTP/1.1 and HTTP/2, it uses QUIC instead of TCP for the underlying connection.
As of October 2025, HTTP/3 is used by 35.9% of all the websites.

Some major improvements of HTTP/3:

Eliminates Head-of-Line Blocking - QUIC handles streams independently. If a packet is lost, only that specific stream is paused while others continue uninterrupted.
Faster Connection Establishment - QUIC builds encryption directly into the protocol, combining the TCP handshake and TLS encryption into a single step, significantly reducing initial connection latency.

HTTP/3 standardized in June 2022 with RFC 9114, RFC 9204 and RFC 9250

DEV Community