摘要

  • 2000 年 10 月的 RFC 2965 设计了一次能力协商：同时懂新旧 Cookie 的客户端，按情形继续发送旧式 Cookie，并用 Cookie2: $Version="1" 宣告理解新版；懂新版的服务器可改用 Set-Cookie2，旧服务器可以忽略宣告。
  • 新式响应中的 Port 属性可限定 Cookie 回送的端口；CommentURL 可提供一处解释用途的页面。客户端自报能力、服务器选用新版、用户阅读说明，是三件不同的事。
  • 2011 年 4 月的 RFC 6265 取代 RFC 2965，要求把后者改列历史状态，并废弃 Cookie2 与 Set-Cookie2。新文本以实际使用的 Cookie 和 Set-Cookie 为核心，同时指出同一主机不同端口之间仍共享 Cookie。

浏览器递上一张能力卡

HTTP 一次请求接一次请求，本身不替网站记住购物篮或阅读进度。服务器发给浏览器一份状态值，浏览器日后在适当请求中送回来。1997 年 2 月的 RFC 2109已经说明了早期的这套做法。接下来的问题更棘手：怎样改进它，同时不把大批仍按旧习惯办事的浏览器和服务器赶出门？互联网没有一只总开关，能在同一天下午替所有人更新软件。

2000 年 10 月的 RFC 2965选择了礼貌的升级方式。它给服务器一个新版响应头 Set-Cookie2，给客户端一个报出自己能力的请求头 Cookie2。一个兼容新旧做法的浏览器，如果最初收到的是旧式 Set-Cookie，仍可按旧式规则回送 Cookie；与此同时，它应发送 Cookie2: $Version="1"。这相当于说：“我还在用旧路，但也认识新路。”

服务器若同样懂新版，就应在之后的会话中使用 Set-Cookie2。不认识 Cookie2 的旧服务器只需忽略它，原先的交换仍能进行。升级没有要求旧软件先通过考试才准继续服务。这是一份为分散系统设计的迁移方案：让新客户端举牌，让有能力的服务器接牌，让旧参与者继续走熟路。

举牌只是第一步。Cookie2 说明客户端声称自己理解哪个版本，不负责承载所有会话值。Set-Cookie2 是服务器发给浏览器的新版状态与属性；后续返回适用状态值的仍是请求中的 Cookie。若在网络记录里只看到 Cookie2，接下来还须看服务器是否回了新版字段、浏览器之后是否回送了值。把这三种头混成同一件事，就会把升级过程误读成一声咒语。

新版设计也把选择权留给服务器。服务器可以发出 Set-Cookie2，浏览器也可以继续请求；应用是否完成了某笔交易，还要看应用层的记录。Cookie 字段的存在只说明一段机器之间的状态交换，不能替用户作决定。

新通道究竟多了什么

在 Set-Cookie2 中，Port 属性提供一个具体的边界。没有该属性时，同一主机的相关 Cookie 可以送回任意端口。写了 Port 却没有值，就只能送回最初收到它的端口；若列出端口，则只能送往名单中的端口。同一台机器上运行两个不同服务时，这比把状态默认横跨所有端口更细。

CommentURL 解决的是另一道题。规范鼓励源服务器解释 Cookie 的用途，并偏好给出一处 URL：页面能容纳更多信息，还可以提供多种语言。把解释放在一个可访问的地方，是给读者留出了解的入口。读者是否打开页面、读懂文字、选择同意，仍要由后续的行为来回答。

因此新版头字段不只是把名字后面加个“2”。它试图提供更窄的端口范围、解释用途的入口，以及发现对端是否支持它的方法。这些好处有一个朴素的前提：浏览器和服务器都必须实际走上那条路。单方面发明一个更精巧的字段，不会让别人的软件自动理解。

2000 年规范花了很多篇幅照顾新旧并行。只懂旧 Cookie 的浏览器不会识别 Set-Cookie2，仍照旧行事。懂两种方式的浏览器则要记住状态值从哪个响应字段而来，以匹配相应的回送规则。若同一响应为等价 Cookie 同时给出旧、新两种字段，支持新版的客户端须以新的为准。兼容性没有免费午餐：旧会话活了下来，新软件得处理两套路径。

这两份 RFC 没有给出各浏览器发送 Cookie2 或各服务器回应 Set-Cookie2 的数量。要重建细致的采用史，需要带日期的软件版本和真实交互记录。但它们已经给出两件可以直接核对的事：2000 年提出了怎样的协商路线，2011 年的规范又把哪条路线放回了中心。

2011 年把新通道关上

2011 年 4 月的 RFC 6265换了出发点。它说自己要描述互联网实际怎样使用 Cookie 与 Set-Cookie，并指出更早的 Netscape 文本、RFC 2109、RFC 2965 都没能准确描述这种用法。它要求服务器尽量按较规整的方式生成 Cookie，同时要求客户端能宽容解析已经在网络里流通的服务器响应。规范先看路上有什么车，再画路标。

在同一开篇，RFC 6265 请求把 RFC 2109 和 RFC 2965 改列历史状态，以自身取代 RFC 2965，并明确废弃 Cookie2 与 Set-Cookie2。头字段登记章节也把两个新版名称标为已废弃。浏览器的能力牌与服务器的新版出票口，正式被移出主合同；旧的 Cookie/Set-Cookie 交换成为新标准记载的日常语言。

2011 年的文本没有把日常语言粉饰成完美方案。它指出，同一主机的 Cookie 会在不同端口之间共享，尽管浏览器对不同端口的内容通常按不同来源处理。这正是 2000 年 Port 属性曾尝试收紧的边界。新版规范记录了运行中的行为，却没有把那项旧分支的端口限制重新装回核心 Cookie 规则。

所以这不是两种头字段谁的名字更漂亮。2000 年的设计把兼容与渐进放在前面；2011 年的设计把可互通的实际用法放在前面。服务器可以选择发新版字段，浏览器可以选择报能力，旧软件可以照着规范允许的方式忽略新字段。每个环节都掌握在不同参与者手中。标准作者能写下迁移路线，不能把所有分散的程序都搬上去。

文书结局很清楚：RFC 2965 被取代，两个头字段被废弃。至于某个浏览器具体何时加入或停止发送 Cookie2，要查它有日期的实现历史。即便没有那份逐版本清单，两份 RFC 的转向已足够醒目：2000 年试图让网络升级的问候语，到 2011 年成了档案里的旧词。

备用道路成了主路

Cookie2 的协商设计并不粗鲁。新客户端先报告能力，新服务器可回新字段，旧参与者仍走旧路。这种安排避免了突然断线，也使新版的好处必须等双边都投入才会出现。服务器可以等更多浏览器，浏览器也可以等更多服务器。等着等着，旧路上已经有整座城市。

2011 年的选择留下具体代价。更细的 Port 回送范围、通过 CommentURL 提供解释的标准路径，留在被废弃的分支里；实际运行的 Cookie 仍面对跨端口共享等问题。把升级写进标准，不等于为升级配置了参与者、测试和部署动力。

互联网规范经常输给自己的兼容安排。一个新办法可以确实解决问题，也可以体贴地允许旧办法继续。倘若旧办法足够让多数应用运行，它就会从过渡方案变成长期制度。Cookie2 是一张准备开新门的名片。十一年后，标准把名片收起，记录了大家实际走过的门。