摘要

  • 10 月 28 日的个人草案提出两种互斥的 OAuth 客户端元数据：client_ip_ranges 直接列出 IPv4、IPv6 前缀，client_ip_ranges_uri 指向 HTTPS JSON 文件。注册元数据或成功下载文件，都不是服务器接受地址范围的决定。
  • 文件取不到、内容无效或客户端撤回声明时，服务器不能因此放进原先被拦的来源。它可保留已接受的旧清单，也可先与待批准的新清单取交集；保留期限到头后，执行门禁的服务器须拒绝客户端请求，直到批准当前清单或明确取消门禁。

文件更新了，通行证还在旧抽屉里

一家服务商把 OAuth 客户端搬到新的云出口。运维人员更新 JSON，服务器下一次抓取也得到 HTTP 200，可从新地址发出的令牌请求仍被拒绝。草案明确区分“取到文件”和“接受其中的范围”。服务器先验证整份清单，再按自己的策略决定是否接受。客户端突然加进一个大前缀，不能靠刷新网页自动取得网络通行权。

声明可以直接放在元数据里，也可以放进 HTTPS 文件；两者不能同时出现。两个字段都没有，意思是没有作出声明。空数组则是声明“没有任何地址”。按 RFC 7592 更新客户端时，草案特意要求服务器把空数组当作有效的空集合声明，不能当成删字段的手势。若服务器接受并执行这个空集合，任何来源 IP 都进不去。

新集合一旦获批，就整份替换旧集合，没有逐条追加的格式。在新集合通过验证、尚未获批的间隙，服务器可以只保留新旧清单交集：先关掉已经不用的出口，暂时不打开新出口。客户端应在流量迁移之前先声明新前缀，在旧出口停止发请求之后才删旧前缀。文件缓存时间和批准延迟都要纳入切换计划。

文件坏了不能把门撞开。抓取失败、格式有误和撤回声明，都不能自动放宽旧限制。撤回后要松绑，须有明确的本地策略决定。服务器还应为旧集合设保留期限：下载持续失败、声明撤回或替代清单久候批准，都开始计时。期限过后，仍执行门禁的服务器要拒绝请求，直到接受当前声明下的新集合，或明确结束这项门禁。反复验证一份尚未批准的替代清单，不能重拨时钟。

旧许可也有代价。客户端离开的地址可能被重新分配，长期保留旧范围就可能把别人发来的包当成可接受来源。取交集和保留期限限制这段窗口。RFC 9111管的是 HTTP 缓存；草案强调已接受的 IP 集合是另一份应用状态。缓存返回 304 Not Modified，不等于政策批准；缓存过期，也不自动撤销已接受集合。

放行 IP 还不等于识别客户端。令牌端点前的防火墙能看到来源地址，未必知道请求属于哪个 OAuth 客户端，只能执行汇总规则。授权服务器识别客户端后，才能逐个执行其已接受清单。若签名声明只包含文件 URL，签名保证的是 URL，不保证托管方今后提供的每一版内容；托管方甚至可能用空清单或长期不可达把客户端挡在门外。

IETF 状态页把它列为个人草案，没有提供实际部署结果。一次真实迁移最该留下的记录，是文件版本、服务器实际接受的集合、批准时间、旧范围失效时间，以及切换前后令牌请求的结果。

资料：草案原文；IETF 状态；RFC 7592；RFC 9111。