From a CERN information problem to HTTP/0.9

HTTP started with an information problem, not a networking blank slate

The Internet, TCP/IP, electronic mail, FTP, network news, and several hypertext systems already existed when Tim Berners-Lee wrote Information Management: A Proposal at CERN in March 1989. The proposal did not claim that networks or hypertext needed to be invented. It described a narrower but difficult problem: CERN’s technical knowledge was distributed across people, projects, machines, documents, and incompatible information systems. People moved on, systems changed, and recorded information became difficult to find.

The proposed answer was a distributed hypertext system. Information could remain on independently managed systems while links connected it into a larger space. That requirement matters to HTTP’s history because it favored a small, open interface between a reader and a remote information source. A central database with one data model would not satisfy the proposal’s stated need for heterogeneity and non-centralization.

The architecture that emerged separated several jobs:

• a URI identified something;
• HTTP transferred a request and response;
• HTML represented linked hypertext; and
• a browser presented and navigated that information.

Those pieces are related, but they are not synonyms. HTTP is not the Web, HTML is not HTTP, and Berners-Lee did not invent the Internet beneath them.

The first implementation made the architecture concrete

By the end of 1990, Berners-Lee had implemented the first Web server and the WorldWideWeb browser-editor on a NeXT computer at CERN. The first website, info.cern.ch, described the project itself and explained how to create servers and find the small number of other sites.

The browser was also an editor. That detail is historically important: the original vision was not only passive publication. The Web was meant to be a shared information space in which following and creating links were closely connected, even though mainstream browsers later emphasized reading over in-place editing.

A line-mode browser followed so the Web was not restricted to NeXT workstations. The simpler client sacrificed the graphical editing environment but improved portability. That tradeoff reflects a recurring Web pattern: a less elaborate component that runs on more systems can expand the network faster than a richer component with a narrow platform requirement.

The original request could fit on one line

The 1991 protocol later called HTTP/0.9 was intentionally small. A client opened a TCP connection, sent GET, a space, and the document path, then ended the line:

GET /hypertext/WWW/TheProject.html

Expected result: the server sends the HTML document as a byte stream and closes the connection when the representation is complete.

There was no HTTP version token on the request line. The response had no status line and no field section:

<title>The World Wide Web project</title>
<nextid N="55"> <h1>World Wide Web</h1></nextid>

Expected result: the client interprets the returned bytes as HTML because the protocol defines the successful response that way, not because a Content-Type field identifies it.

The name “HTTP/0.9” is retrospective. The original document describes “the original HTTP as defined in 1991”; later specifications needed a label for this simple form when distinguishing it from full HTTP messages.

What HTTP/0.9 deliberately did not provide

Modern HTTP users notice the absences immediately:

• no machine-readable success or error status;
• no response fields;
• no representation metadata;
• no content negotiation;
• no request content;
• no standard methods beyond GET;
• no persistent connection; and
• no way to host several named sites on one IP address through a Host field.

An error was an HTML document written for a person. A client could not reliably distinguish that error from a successful document except by understanding the text. The response ended when the server closed the connection. The protocol assumed HTML rather than describing an open set of media types.

These were not all oversights. A one-line protocol was enough to validate the core loop: identify a remote document, ask for it, receive hypertext, and follow another link. Every extra negotiation rule would have increased implementation work before the network had demonstrated value.

The design notes already looked beyond simple retrieval

The surviving 1991 design documents show that the team understood the simple protocol would not be the final form. They discuss:

• machine-readable status codes;
• format negotiation;
• a HEAD operation for metadata without a document;
• authentication information;
• redirection to another address;
• search operations; and
• gateways to existing information systems.

One design note explicitly favored an Internet-style text protocol because it was familiar, implementations were widely possible, and simplicity would help it “catch on.” RPC and OSI-based alternatives were considered. The choice was therefore not “text because nobody imagined binary protocols.” It was a deployment decision: optimize the first interface for understandability, portability, and participation.

The same notes describe the protocol as idempotent and stateless in the sense that a server did not need to preserve client session state after a request. Modern HTTP has more precise method semantics, and applications routinely build stateful experiences above HTTP. The lasting architectural point is that the base exchange did not require a dedicated conversational session like FTP’s current directory and transfer mode.

Growth depended on more than protocol syntax

Protocol design alone did not spread the Web. CERN made server, line-mode client, and library code available; developers created browsers for additional platforms; the NCSA Mosaic browser made graphical navigation accessible to a much wider audience; and on 30 April 1993 CERN issued a statement allowing the core Web software to be used, copied, modified, and distributed without fees.

Open implementation and open specifications reinforced each other. A protocol can be publicly documented yet remain irrelevant if useful interoperable software is inaccessible. Software can be available yet fragment if the shared wire contract is proprietary or unstable. The early Web combined both forms of openness.

The smallest protocol established durable boundaries

HTTP/0.9 did not contain modern HTTP, but it established several choices that survived:

1. The client initiates a request for an identified target.
2. The server sends a response representation.
3. The protocol is independent from the user interface.
4. Links can cross administrative and machine boundaries.
5. Servers can expose existing information without moving it into one central repository.
6. The basic interaction is simple enough for independent implementations.

Later HTTP versions added metadata, negotiation, methods, caching, persistent connections, binary framing, multiplexed streams, and a new transport. They did not discard the central act demonstrated in 1990: a client names something, requests it through a common interface, and receives a representation from a remote system.

That continuity is the first major lesson of HTTP’s history. A successful protocol can radically change its wire machinery while preserving the application model that made the network useful.