Undici 项目中的 HTTP 缓存与 ETag 实现探讨

Undici 作为 Node.js 的高性能 HTTP/1.1 客户端，近期在实现 HTTP 缓存功能方面取得了重要进展。本文将深入分析当前实现状况，并探讨如何进一步完善 ETag 和 If-None-Match 支持。

当前缓存实现现状

Undici 的最新开发中已经引入了基于 RFC9110 标准的 HTTP 缓存功能。目前该实现主要支持通过 If-Modified-Since 头部进行缓存验证，当服务器返回 304 Not Modified 状态码时，客户端能够透明地返回缓存的 200 OK 响应，这与浏览器行为保持一致。

ETag 机制的重要性

ETag 作为 HTTP 缓存验证机制的另一重要组成部分，其实现具有独特价值：

• ETag 提供更精确的资源变更检测，不受时钟同步问题影响
• 适用于动态内容，即使修改时间相同但内容变化也能被识别
• 支持弱验证模式，允许非严格的内容变更判断

技术实现考量

完整的 ETag 支持需要考虑以下技术细节：

1. 缓存存储设计：需要扩展现有缓存存储结构，保存 ETag 头部信息
2. 请求协商机制：自动将存储的 ETag 值附加到后续请求的 If-None-Match 头部
3. 响应处理流程：正确处理 304 响应，返回缓存的完整响应
4. 开发者体验：提供缓存状态的可观测性，便于调试和监控

与 Fetch 规范的兼容性

值得注意的是，Fetch 规范将 304 状态码归类为"null body status"，与 101 和 204 状态码类似。Undici 需要确保其实现既符合规范要求，又能满足 Node.js 开发者对缓存状态可见性的需求。

未来发展方向

理想的实现应该考虑：

• 提供缓存状态指示机制（如特殊头部或响应属性）
• 支持多种验证策略组合（ETag + Last-Modified）
• 确保与浏览器行为的一致性
• 提供细粒度的缓存控制选项

通过完善这些功能，Undici 将成为 Node.js 生态中更加强大和全面的 HTTP 客户端解决方案。