Summary

  • The original HTTP described for the 1991 World Wide Web sent a single GET request and returned an HTML document whose end was signaled by the server closing the connection.
  • That compact exchange had no status line or headers. Its own design notes say an error came back as a document and could not be distinguished from success except by reading its text.
  • HTTP later added a versioned request, headers and status codes while retaining the simple form for compatibility; the surviving trace is a deliberate compatibility boundary, not a measure of how widely HTTP/0.9 was used.

The page was the whole reply

In the World Wide Web’s 1991 implementation, the conversation began after a client opened a connection to a server. If no port appeared in the address, the client used port 80. It then sent a line containing GET and the document address. The server answered with a stream of HTML text. When it had sent the document, it closed the connection. There was no separate status line before the page and no header block after it. The first bytes belonged to the document.

This was not a protocol with an invisible HTTP envelope around every page. Tim Berners-Lee’s archived description calls the reply a message in HTML, says the connection close terminated it, and explains that a server could send readable error text in HTML. The same description identifies the cost directly: there was no way to distinguish an error reply from a satisfactory one except through the text itself. A browser could display the page it received, but the wire format supplied no machine-readable “not found,” redirect, or server-error code.

The June 1992 summary made the design tradeoff plain. The browser sent one command, GET, followed by a document identifier that could include keywords for a named index. The server did not keep state about the browser. The response could be HTML or plain text, and the response itself could contain a menu, a hit list, or a document. The summary praised the simplicity: there was nothing beyond marked-up text coming from the server. Yet it also named the missing boundary. HTTP information, document contents, and document kind had no lexical distinction. Error messages were just documents, and a reader might ignore them.

That ambiguity was a property of the message format, not proof that early servers routinely failed or that users could not understand an error page. A human could read the body. A program had no status field to inspect. And because the response ended with connection closure, the protocol used the same event both to mark the normal end of a document and to terminate an interrupted exchange. The boundary told a client that the stream had stopped; it did not say why.

The early design also was not limited to static pages. An ISINDEX element could signal that a browser should construct a query by appending keywords to the document identifier. The server could return an HTML hit list. Berners-Lee’s 1991 account of HTTP’s intended role also names index search, format negotiation and referral to another server among the capabilities an information-access protocol needed. Those were goals for the broader design; they should not be mistaken for features already provided by the one-line simple exchange.

Why the simple reply changed

By December 1992, the public www-talk discussion shows a proposed path toward a fuller protocol. Berners-Lee wrote that new servers should continue to recognize the existing GET <url> request. A client could add a version token on the same line, followed by headers such as From, Accept and Accept-Encoding. His example response included a version, a response field, a MIME content type and supported methods. It was a proposal, not a final wire capture or proof of deployment, but it shows the design problem being opened up: a response needed to carry information about itself as well as its content.

RFC 1945, published as an Informational RFC in 1996, later described both forms. The simple request remained one GET and a URI, with no header fields; the simple response remained only an entity body and ended when the server closed the connection. A fuller response began with a status line and could include response and entity headers. The RFC specifically warned that the simple request prevented a server from identifying the returned media type. Keeping the old form recognizable let newer HTTP systems account for earlier clients and servers without pretending they sent the same message.

The chronology matters. The RFC’s retrospective definition is a useful account of compatibility, not evidence that “HTTP/0.9” was a separately ratified standard in 1991. Berners-Lee later recalled that the first Web server and client software, including Nicola Pellow’s line-mode browser, reached the high-energy-physics community and then hypertext and NeXT communities in summer 1991. He also said the URI, HTML and HTTP specifications were published on the first server to encourage discussion and adoption. Those sources place the protocol in its experimental setting; they do not count how many installations used each message form.

A document-only reply made a small system legible: ask for a resource, receive material a browser could show. Its limit appeared when the client needed to reason about the reply as a protocol event. Without a status line, an HTML error and an HTML page occupied the same place in the exchange. HTTP’s fuller messages added a machine-readable boundary between outcome, metadata and content. The old reply remained as a simple form that a later protocol could still recognize.

Sources