Summary

  • MCI’s 1994 marketplace project needed order, billing and shipping information to persist across Web requests. Its team rejected Netscape’s initial server-side proposal and required state to be stored on the client.
  • Netscape turned the customer’s requirement into a general browser feature. A cookie let a server send a state value that the browser could return on later matching requests; it did not, by itself, establish who was holding the browser.
  • RFC 2109 later tried to formalize a mechanism already shaped by implementation and compatibility. Its own rules treated user control, readable values and insecure transport as real limits.

A basket made statelessness a product problem

The Web’s familiar request-and-response pattern had a practical gap. An HTTP request could ask for a page and receive it, but the next request did not automatically carry the application’s history. A merchant could keep that history on its own server, yet then it had to manage the state and the records left behind when a browser disappeared.

MCI was building marketplaceMCI as an online shopping environment. The system was meant to combine an MCI-branded browser, a Web server, merchant servers for receiving and filling orders, and back-end systems for support and merchant accounts. The commercial task was concrete: move order, billing and shipping information through a sequence of requests.

The important design choice appears in a later court record, not in a folklore account of a lone inventor. On 10 August 1994, MCI rejected Netscape’s initial suggestion to keep the state on a server. It required the information to be stored on the client computer. The record describes that general requirement as undisputed, while preserving disagreement over some technical details.

That requirement changed the location of the application’s short-term memory. The browser would hold a small state object between visits to a server. Netscape programmer Lou Montulli was assigned work on the problem. Montulli later recalled being asked to devise a shopping-cart method for HTTP’s sessionless nature, though he did not recall that MCI was the specific customer. Marc Andreessen testified that the MCI project eventually led to cookies and that Netscape broadened the feature for general use. Those accounts connect a customer need to a product decision without making every detail of the design history certain.

The browser became a carrier of application state

The preserved Netscape specification explains the mechanism in simple terms. A server could return a state object alongside an HTTP response. The browser stored it, then included it with later requests whose URL matched the cookie’s scope. The server application chose the value and interpreted it; the browser’s role was to retain and return it.

That was enough to let an application carry a basket reference, registration value or preference from one request to another. It did not make HTTP a continuously connected protocol. It did not require the page itself to contain each visitor’s basket, which mattered to Web caching. And it did not mean the server had stopped doing work: an application could still use the returned value as a key to records it retained elsewhere.

The Netscape text also called itself a preliminary specification and advised readers to use it with caution. Its early rules covered such details as host or domain, path, expiry and secure transmission. These were practical boundaries for deciding when a browser would return state. They were not proofs of the user’s name, consent, or continued presence.

The record places draft cookie code in Netscape’s source repository by 3 or 4 October 1994, with later changes on 6 and 13 October. The parties in the case disputed the precise date when the invention was reduced to practice. The defensible chronology is therefore a summer design and customer requirement, working code by early October according to the court’s account, and a feature being generalized for Netscape’s browser. It is not a single uncontested “invention day.”

A standard arrived after a browser proposal

In February 1997, David Kristol and Montulli published RFC 2109, “HTTP State Management Mechanism.” It described Set-Cookie responses and Cookie requests, and tried to put the exchange into a standards-track grammar. The document explicitly included a historical section for compatibility with Netscape’s original proposal. Standardization was therefore also an exercise in accommodating code and behavior already in circulation.

RFC 2109 made the mechanism’s limits unusually visible. A user agent was to give people control over whether cookies were sent and retained. The header contents travelled unprotected, so sensitive values could be exposed or altered. The RFC called a cookie value opaque from the browser’s perspective, but acknowledged that it might be readable. Its login example first has the user identify themself through a form; the server then returns a cookie reflecting that identity. The cookie carries the application’s state after the identity step. The exchange does not make the cookie an independent identity check.

That boundary matters because a browser-held value can be useful to a service and still be a weak claim about a person. If an application treats possession of a value as authority, it has created a bearer-style session capability. Anyone who obtains the value may be able to reuse it within its scope and lifetime. Whether that is safe depends on how the application issues, protects, expires and revokes it—questions the basic cookie exchange does not answer by itself.

The cookie’s historical significance is less mystical than its name suggests. A shopping flow forced a product team to choose where continuity would reside. A browser became the courier for state selected by a server; a customer-specific request became a reusable feature; and a later standards effort recorded compatibility with deployed practice. The result let Web applications remember a transaction across otherwise separate requests. It never made the browser a witness to the human identity behind them.

Sources and limits