Summary

  • IETF CDNI 工作组草案 10 月 27 日发布的第 -13 版点出缓存交接风险：合规来源得到带 * 的 CORS 响应后，若共享缓存没有正确执行 Vary，白名单外来源也可能拿到它。
  • 草案同时说清控制发生在哪里：CORS 响应头指示浏览器能否把已收到的公开资源暴露给跨域脚本；下游 CDN 仍会提供资源。

会场门卫核对名单，给入场者一只金色手环。旁边的寄存柜却把同样的手环递给了名单外的人。门卫没有看错；“谁获准”这件事在交接中被弄丢了。IETF 新版 CDNI 边缘控制元数据草案描述的正是这类交接：上游 CDN 定规则，下游 CDN 回响应，共享缓存复用结果。

上游 CDN 可以经由 RFC 8006 所定义的元数据接口发送 MI.CrossoriginPolicy，列出允许的网页来源。下游节点将请求里的 Origin 与名单比较。如果匹配且启用 wildcard-return，响应可携带 Access-Control-Allow-Origin: *；不匹配则不附相应的 CORS 响应头。问题是，那个星号本身没有写明是哪一个来源通过了检查。

新版草案把共享缓存的陷阱写进运营章节：如果缓存把原本送给获准来源的带星号响应，未经来源区分就交给被排除来源，后者的浏览器也可能看到这张“手环”。草案要求下游 CDN 对每个响应重新生成 CORS 头，不能把它当作资源内容一起缓存；会影响生成结果的请求头名称必须列入 Vary。这里的 Origin 不是装饰，它决定这份响应头该给谁。

旧的第 -12 版已描述元数据对象；第 -13 版把边界讲得更明白。CORS 是浏览器对脚本能否读取响应的检查，不是下游 CDN 拒绝提供公开资源的开关。响应缺少 CORS 头时，CDN 仍可送出资源，符合规则的浏览器则不给跨域脚本读取。带浏览器凭据的 include 请求超出这套对象的范围，认证与授权需要额外行为。

政策传输还有时间差。上游先让资源上线、规则却还没抵达下游时，下游会暂时送出没有 CORS 头的响应，浏览器的跨域检查因此失败。新增的运营章节指出，运营者可通过已有 RFC 8006 接口取回下游当前配置，再与观察到的响应比较；草案没有另造一套监测系统。上游“我发了”、下游“我收了”、浏览器“我看到了”，各是一份凭据。

IETF 文件页显示第 -13 版仍处于 IESG 评估。对共用交付链的运营者，真正的问题是：门卫查了名单之后，谁还在检查寄存柜发出的手环？