Undici缓存处理机制中的URI失效范围问题分析

在Node.js的HTTP客户端库Undici中，缓存处理器(cache-handler)对于非安全HTTP方法(POST/PUT/DELETE等)的响应处理存在一个关键设计问题。当收到这些方法的成功响应时，当前实现会错误地使整个源(origin)下的所有缓存失效，而根据HTTP规范，这应该仅限于目标URI(target URI)。

问题本质

Undici的缓存处理器在收到非安全方法(unsafe methods)的成功响应时，会执行以下逻辑：

1. 识别请求方法为POST/PUT/DELETE等
2. 收到2xx或3xx的成功响应状态码
3. 清除该源(origin)下的所有缓存条目

这种行为过于激进，会导致缓存的有效性大幅降低。例如，一个频繁调用的POST请求会使整个域名的缓存几乎持续处于无效状态。

HTTP规范解读

根据HTTP/1.1规范(RFC 9110和9111)：

• 缓存必须在收到非安全请求方法的成功响应时使目标URI失效
• 目标URI应理解为完整的请求URL，包括路径和查询参数
• 失效范围不应扩展到同一源下的其他资源

举例说明规范预期行为：

• 当DELETE请求http://example.com/foo/bar成功时
• 仅应使http://example.com/foo/bar的GET缓存失效
• 不应影响http://example.com/other/path等无关资源的缓存

影响分析

当前实现会导致以下问题：

1. 缓存命中率显著下降
2. 系统性能受到影响
3. 与HTTP规范不符可能导致兼容性问题
4. 对于RESTful API密集的应用场景特别不利

解决方案建议

正确的实现应该：

1. 精确识别需要失效的URI
2. 仅清除与该URI直接相关的缓存条目
3. 保留同一源下其他资源的缓存
4. 考虑实现更细粒度的缓存控制策略

开发者启示

这个问题提醒我们在实现HTTP缓存时需要注意：

• 严格遵循相关RFC规范
• 理解URI和origin的概念差异
• 设计合理的缓存失效策略
• 在性能与正确性之间取得平衡

对于使用Undici的开发者，建议关注此问题的修复进展，在关键业务场景可能需要暂时实现自定义缓存处理器来规避这个问题。