摘要

  • RFC 2109 用 Set-Cookie 与 Cookie 把彼此独立的 HTTP 请求和响应编成逻辑会话，并明确说明这不是持久网络连接。
  • Domain、Path、Max-Age、Secure 与缓存控制限定状态的流动；规范还要求用户拥有控制权，并约束自动加载和重定向产生的“不可验证事务”。
  • Cookie 返回只能证明用户代理按规则选择了服务器定义的状态，不能证明当前的人、知情同意、授权、新鲜度、交易意图或应用结果。

连接断了，记忆仍可继续

RFC 2109 把会话定义为多个 HTTP 交换之间的逻辑上下文。它特意排除了一个常见误解：这里的会话不是持久网络连接。连接可以复用、关闭或重建，Cookie 会话仍可延续；反过来，连接还活着，也不说明服务器仍承认旧会话。

源站用 Set-Cookie 发起，用户代理可在后续请求中带上 Cookie，双方都可以结束这段上下文，服务器还可用 Max-Age=0 要求删除。传输连接、浏览器中的保存状态与服务器端的会话有效性因此是三张不同的收据。

商店示例证明了机制，也暴露了越界

示例先保存 Customer，再保存 Part_Number 和 Shipping。请求路径符合条件时，浏览器自动把它们带回。这足以证明连续性：服务器曾发值，客户端曾保存，选择规则在后来命中。

但 Customer 只是应用选定的名字。它可能指向数据库记录，也可能是可读文本。返回该值并没有重新认证键盘前的人；旧的 Shipping 也不是此刻对订单的确认。最后一个 HTTP 成功响应更不能单独证明扣款、出库或送达。

范围回答“何处发送”，不是“谁有权决定”

Cookie 的值对用户代理是不透明的，却可能被检查报文的人读到。Domain 采用当时的域匹配规则，Path 选择 URI 前缀，Max-Age 表示预期寿命，Version=1 标识机制版本。若多个 Path 同时匹配，更具体的值排在前面，同名 Cookie 甚至可以重复出现。

这些属性只回答何时把哪些字节放进请求。Path 不是保密边界；共享 Domain 也不等于其中每个服务都获得同等业务权限。服务器仍须解释并验证收到的状态。

Secure 的措辞尤其克制：它是服务器给用户代理的安全建议，什么算“安全手段”由用户代理判断。该属性本身不加密内容，不认证人，也不把一次敏感操作绑定到当前授权。安全章节另行警告，明文头字段可能被窃听或篡改。

会话状态不能吞掉缓存模型

RFC 2109 把状态与 URL、文档内容分开，一个重要原因是保留缓存带来的扩展能力。公共表示仍可复用，私人会话内容不应留在共享缓存。代理要转发 Cookie 字段，同时遵守 private、普通有效期和 no-cache="set-cookie" 等控制。

因此，缓存中有一份表示、响应中出现 Set-Cookie、浏览器真正保存状态、源站后来接受会话，是四个事件。RFC 2068 提供了当时 HTTP/1.1 的缓存语义；旧式 HTTP/1.0 缓存缺少压制单个头字段的通用能力，可能把 Set-Cookie 一并缓存，形成安全问题。

自动重放已经被视为隐私风险

RFC 2109 把用户能提前查看请求 URI 的交互称作“可验证事务”；自动加载的嵌入对象和重定向通常属于“不可验证事务”。它试图阻止一个源站诱导浏览器在无关域上开始或延续会话，任何覆盖选项都应默认关闭。

这个历史术语并不等于现代浏览器的完整安全模型，但它准确指出了一种控制矛盾：Cookie 有用，是因为浏览器会自动重放；Cookie 危险，也可能因为这次重放没有新的人的动作。

隐私章节还要求用户可以关闭保存与发送、看见会话是否正在进行、按 Domain 决定保留，并检查 Cookie 内容。规范承认，即使当时看不出身份，路径跟踪也可能令人反感；以后填写的身份表单又可能把此前轨迹连接到一个人。

RFC 2964 后来把知情同意说得更直接，RFC 2965 根据实现经验取代 RFC 2109，RFC 6265 再记录广泛部署的实际语义。当前 RFC 10025 作者校样 属于更新一代。规范更替能证明文本演进，不能证明某款浏览器在某天已经切换。

让每一层只说自己知道的事

可信的审计链应分别写明：服务器发出、用户代理接纳、用户保留、请求上下文选择、服务器会话接受、策略授权、操作提交、结果观察。一个 Cookie 头只占其中一段。

Lu Heng 的 Running-Code Primacy 要求把技术断言拉回真实执行，Minimum Initial Specification 要求把共同层保持在最小范围，Reality Layers 则反对一层记录借用另一层的权威。RFC 2109 的历史价值正是：它标准化了记忆，却没有因此标准化人的授权。

来源