Summary

  • RFC 2965 in October 2000 offered an upgrade handshake. A client supporting both old and new cookie handling should advertise Cookie2: $Version="1" while continuing to send an older Cookie when appropriate. A server that understood the new style should continue with Set-Cookie2; an older server could ignore the announcement.
  • The new response header could carry a Port attribute to restrict where a cookie returned and a CommentURL to provide information for user consent. Neither field, by itself, proved that a client took the upgrade or that a user read and accepted the explanation.
  • RFC 6265 in April 2011 obsoleted RFC 2965, asked for its status to become Historic, and deprecated both Cookie2 and Set-Cookie2. It defined the Cookie/Set-Cookie pair as used on the Internet and noted that cookies for one host remain shared across ports.

The browser offers to speak a new dialect

A server wants to remember something across HTTP requests. It sends a cookie to a browser; the browser returns the applicable value later. That basic exchange was already familiar when RFC 2109 appeared in February 1997. The later question was how to introduce a richer version while the web still had clients and servers speaking older cookie dialects. No central switch existed to upgrade them all on one afternoon.

RFC 2965, published in October 2000, tried a courteous negotiation. It specified Set-Cookie2 for a server's newer response and Cookie2 for a client's capability announcement. A client that understood both the new rules and older Netscape-style cookies should keep sending an old-style Cookie for a cookie received through Set-Cookie. Alongside it, the client should send Cookie2: $Version="1". That second field said, in effect, “I can understand the new version.”

The other end had a choice. A server that also understood the new style should continue the session with Set-Cookie2 rather than the older Set-Cookie. A server that did not understand the announcement could simply ignore Cookie2. The old conversation would continue. The design gave an updated browser a way to reveal its ability without forcing a legacy server to learn new words before answering.

That is a capability signal, not a receipt. The presence of Cookie2 would show what the client claimed to understand, not that the server switched, that the user accepted anything, or that a particular cookie was later returned. The following response and requests would carry those separate facts. A protocol upgrade has stages; a badge flashed at the door is only the first one.

RFC 2965 also distinguished the two directions of cookie traffic. Set-Cookie2 was a response header from origin server to user agent. The user agent stored eligible values and later returned them in a Cookie request header under the newer rules. Cookie2 did not carry a session value as a replacement for Cookie; it told the server which version the client could speak. Confusing those fields turns the negotiation into a magic incantation and hides the actual state exchange.

Why the new dispenser looked attractive

The versioned scheme offered concrete controls. One was the Port attribute in Set-Cookie2. Without it, the RFC allowed a cookie to return to any port on the relevant host. With Port present but empty, the cookie was limited to the port from which it had been received. With a list, it could return only to listed ports. A service running beside another service on the same machine could at least express a narrower intended return path.

Another was CommentURL. The specification encouraged an origin server to provide information about its use of cookies, preferably through a URL that could carry richer explanations in more than one language. That is an interesting recognition of the user as more than a passive cookie jar. Yet a server's inclusion of a CommentURL was an opportunity to explain, not evidence that anyone opened the page, understood it or consented to a particular transaction. The field could offer a door; it could not walk the user through it.

The upgrade therefore had stakes beyond punctuation in header names. Port proposed a more specific scope. CommentURL proposed a channel for explanation. Cookie2 proposed a way for old and new participants to discover one another without breaking the old session. The system still needed enough clients and servers to honor those promises. A standard can define the upgraded lane; the installed population decides whether traffic enters it.

The compatibility rules were detailed because the old lane remained real. RFC 2965 said an older client that did not recognize Set-Cookie2 would keep dealing with older Set-Cookie behavior. A client supporting both styles had to distinguish where it received a cookie and which request syntax to use. If a response contained both old and new fields for an equivalent cookie, the new-style value was to win for a supporting agent. Those rules made coexistence possible, but also made implementation and testing a two-track job.

Nothing in this paper trail establishes a count of browsers that sent Cookie2 or servers that answered with Set-Cookie2. The RFC describes the expected behavior of participants that implement it. A dated set of client releases and server logs would establish how far the announcement traveled. The later standards decision, however, records where the protocol editors placed their bet.

The 2011 standard closes the new lane

RFC 6265, published in April 2011, made a sharp change in approach. It defined the Cookie and Set-Cookie headers as they were actually used on the Internet. Its introduction said earlier descriptions, including the Netscape text, RFC 2109 and RFC 2965, did not describe that real use adequately. The new document gave servers a restrained profile for generating cookies and clients more liberal parsing rules to interoperate with existing servers. It was a standard written to meet the traffic on the road.

In the same introduction, RFC 6265 asked to move RFC 2109 and RFC 2965 to Historic status, obsoleted RFC 2965 and deprecated Cookie2 and Set-Cookie2. Its header registration section marks the two versioned names as obsoleted. The capability badge and its matching response chute went into the archive. The central contract named the older Cookie/Set-Cookie pair.

This was not a return to a spotless cookie design. The 2011 document itself names security and privacy flaws in the deployed model. It states, for example, that cookies for a host are shared across ports even though browser same-origin rules normally distinguish content by port. That is precisely a boundary for which the 2000 Port attribute had offered a narrower expression. The later standard described what participants were using; it did not revive the versioned port control by another name.

That distinction matters when telling the history. The 2000 text did not fail because its header names looked ugly, and the 2011 text did not declare that every older behavior was ideal. RFC 6265's claim was about interoperability with deployed software. The protocol could not make client capability advertisements valuable merely by specifying them. A newer, richer mechanism that only some endpoints could speak had to compete with a simpler exchange that applications were already built around.

The documentary outcome is firm: the fields were deprecated and the preceding RFC was obsoleted. A more granular story about which browser shipped or removed Cookie2 on which date would need implementation records. The two RFCs already show the decisive institutional reversal: the standards-track upgrade negotiated in 2000 became the historical branch, while the ordinary headers became the 2011 center.

An upgrade can be designed and still lose its constituency

The lesson is about authority, not nostalgia for a lost header. RFC 2965 tried to make migration gradual. A browser could declare capability; a server could choose a new response; a legacy peer could ignore an unfamiliar field. This was a sensible way to avoid breaking old sessions. It also made the new protocol optional at both ends of every conversation. The system would only matter when enough software participated.

By 2011, the standards authors chose to describe the cookie exchange that had a constituency. The richer header pair was retired. The costs are visible in the text: port-specific return scope and a standard explanatory URL remained features of the older branch, while the actual web cookie contract continued with cross-port sharing and separate, imperfect user controls. A formal upgrade path cannot force distributed participants to move together.

The general rule is harsh on protocol designers. A new feature may solve a real problem and have a polite fallback. The fallback can also become permanent if the running clients and servers see enough value in staying there. Cookie2 was designed as the little announcement that would open the new lane. Eleven years later, the standards record put the announcement away and wrote down the route traffic had taken.