Summary

  • RFC 2109 standardized Set-Cookie and Cookie as a way to place separate HTTP exchanges inside a logical session, explicitly independent of a persistent network connection.
  • Domain, Path, Max-Age, Secure and cache controls bounded where state travelled and how content could still be cached; the specification also required user control and constrained automatic embedded or redirected requests.
  • A returned value proved that a user agent selected server-defined state under those rules. It did not prove the current human, informed consent, authorization, freshness, transaction intent or application success.

A label crossed the wire

RFC 2109 opens a durable question with a very 1997 shopping example. The server sends Set-Cookie: Customer="WILE_E_COYOTE". The browser later returns that value, then accumulates another cookie for Part_Number and another for Shipping. The narrative says the first cookie reflects identity, the next reflects a basket item and the last a shipping choice.

The wire record is narrower. It shows that an origin server chose names and values, a user agent retained them, selection rules found them applicable to later request URLs, and the browser replayed them. “Customer” is a server label. It may point to a database row, a session record or readable text. It does not authenticate whoever now controls the browser. “Shipping” records state supplied earlier; it is not a fresh confirmation at the moment of purchase. An HTTP success response is not, by itself, proof that a warehouse, payment rail or delivery system completed its work.

That restraint does not diminish the invention. It explains it. HTTP could remain mostly stateless at the message layer while applications assembled requests and responses into a larger context. A shopping basket no longer had to live in the URL or the document body. A magazine could remember earlier reading. A server could issue opaque state and receive it later without requiring every request to carry a human-readable history.

The session was logical, not a connection

RFC 2109 says explicitly that its session is not a persistent network connection. Connection reuse or closure should not change whether a cookie-derived session continues. The origin server initiates with Set-Cookie; the user agent may continue by returning Cookie; either side may end the context, and the server can request deletion with Max-Age=0.

This distinction prevented transport machinery from inheriting application meaning. A TCP connection can carry many HTTP messages and then disappear. A logical session can cross several connections. Conversely, a live persistent connection does not prove that the application accepts an old session. Connection continuity, stored browser state and server-side session validity are three different records.

RFC 9110 preserves the broader architectural lesson: HTTP message semantics do not turn a connection into a user identity. RFC 2109’s contribution was to put application memory into explicit fields instead of asking the transport to impersonate it.

Scope selected state; it did not create authority

The origin server supplied an opaque NAME=VALUE pair. The user agent was not expected to interpret its business meaning. Domain identified a host scope under RFC 2109’s historical matching rules. Path selected request-URI prefixes. Max-Age set an intended lifetime. Version=1 identified the proposed mechanism. Comment could explain purpose to a person inspecting the cookie.

Secure was unusually candid. It was advice to use a secure means; the user agent could decide what level it considered appropriate. The attribute did not encrypt the value, attest the human at the keyboard or bind a high-risk action to a current mandate. The security section separately warned that clear-text headers exposed and permitted alteration of sensitive information.

Applicable state was chosen from request host, request URI and age. More specific Paths came first, and the same cookie name could occur more than once. Path was therefore a routing selector inside the cookie mechanism, not a confidentiality boundary. Domain limited reach under the rule then specified; it did not certify that every service in the scope had equal authority.

Memory had to coexist with caches

One reason for separating state from both URL and document content was the scaling value of caches. RFC 2109 wanted public representations to remain reusable while private session content and a user-specific Set-Cookie field received stricter treatment. Its caching-proxy section told intermediaries to pass cookie fields, apply ordinary validity rules and respect controls such as private and no-cache="set-cookie".

That design exposes four different facts: a representation was cacheable; a particular response contained Set-Cookie; a user agent retained state; and an origin later accepted or rejected a session. None substitutes for the others. A cached public front door may be useful, yet it may prevent the origin from seeing the request needed to start a new session. An HTTP/1.0 cache could retain Set-Cookie because older protocol machinery lacked a general way to suppress caching individual fields.

RFC 2068 supplied the contemporary HTTP/1.1 cache vocabulary. RFC 2109 used that vocabulary to keep session memory from swallowing the Web’s shared-delivery model.

The specification saw automatic replay as a privacy problem

The most revealing part of RFC 2109 is not the shopping cart. It is the distinction between verifiable and unverifiable transactions. A request was verifiable when the user could review its URI before it was used. Automatically fetched embedded objects and redirected requests were typical unverifiable transactions. The RFC tried to stop one origin from causing the browser to start or continue a cookie session with an unrelated domain; any override was to default off.

The vocabulary belongs to its time, but the control problem is current. A browser can send state because selection rules match, not because a person has just considered that destination. Automatic replay is precisely what makes cookies useful and what makes them capable of carrying ambient authority.

The privacy section went further. Users had to be able to disable saving and sending, see whether a stateful session was active, control persistence by Domain and inspect stored contents. The text acknowledged that tracking could feel intrusive even before identity was evident—and that later form data could connect the trail to identifying information.

RFC 2964 later framed use policy around informed consent, while RFC 2965 replaced RFC 2109 after implementation experience. RFC 6265 then documented the widely deployed cookie model and its security and privacy infelicities. The current RFC 10025 author-review text belongs to a later generation again. This lineage is evidence of changing specifications, not proof that every deployed browser changed at publication time.

What a returned cookie can honestly prove

A request bearing Customer="WILE_E_COYOTE" proves that this request contained those bytes. With surrounding records, it may also prove that a browser selected them for a host, path and time window. It does not prove that Wile E. Coyote is a real account, that the present actor authenticated, that the actor saw the destination, that a purchase remained authorized, that the instruction is fresh or that the advertised result occurred.

The defensible evidence chain keeps separate verbs: server issued; user agent admitted; user retained or deleted; request context selected; server-side session accepted; policy authorized; action committed; effect observed. RFC 2109 standardized the first replayable bridge in that chain. It did not collapse the chain into a cookie.

Lu Heng’s Running-Code Primacy asks technical claims to return to executable facts. Minimum Initial Specification keeps the common layer thin and leaves later decisions local. Reality Layers warns against letting one symbolic record borrow the authority of another. RFC 2109 is a compact historical example: useful shared state at the protocol layer, with identity, consent and business outcome still waiting above it.

Sources