CommaFeed中ETag与Last-Modified同步更新的问题分析

在RSS订阅服务CommaFeed中，我们发现了一个关于HTTP缓存头处理的潜在问题。这个问题涉及到ETag和Last-Modified两个HTTP响应头的同步更新机制，可能导致不必要的网络请求和资源浪费。

问题背景

CommaFeed作为一个RSS阅读器，需要定期从源服务器获取订阅内容更新。为了优化性能，它使用HTTP缓存机制，特别是ETag和Last-Modified这两个头部字段。ETag是服务器为特定资源生成的唯一标识符，而Last-Modified则记录资源最后修改时间。

问题现象

当CommaFeed获取一个feed时，如果服务器返回的ETag值发生变化但Last-Modified保持不变，CommaFeed不会更新本地存储的ETag值。这导致后续请求中继续使用旧的ETag值，使得条件请求失效，实质上变成了无条件请求。

技术影响

这种不一致的处理方式会导致几个问题：

1. 缓存效率降低：客户端无法有效利用ETag进行条件请求，增加了不必要的完整数据传输
2. 服务器负载增加：源服务器需要处理更多完整响应而非304 Not Modified响应
3. 客户端资源浪费：需要处理更多不必要的数据解析和存储

解决方案

正确的实现应该是：

1. 每次获取feed更新时，无论Last-Modified是否变化，都应检查并存储最新的ETag
2. 同样地，无论ETag是否变化，都应检查并存储最新的Last-Modified
3. 两个缓存头应该独立处理，互不影响

实现原理

在HTTP协议中，ETag和Last-Modified虽然都用于缓存验证，但工作机制有所不同：

• ETag通常基于内容哈希生成，内容变化就会改变
• Last-Modified基于时间戳，可能因为服务器时钟同步等原因不够精确

因此，即使Last-Modified不变，ETag变化也表明内容确实有更新，客户端应该接受这种变化并更新本地存储。

最佳实践

对于类似CommaFeed这样的订阅服务，处理HTTP缓存头时应遵循以下原则：

1. 优先使用ETag进行条件请求，它比Last-Modified更可靠
2. 同时支持两种验证机制，提高兼容性
3. 独立存储和更新两个缓存头
4. 在条件请求中同时发送If-None-Match(ETag)和If-Modified-Since(Last-Modified)

这个问题已在CommaFeed的最新版本中得到修复，确保了缓存头处理的正确性，提高了订阅更新的效率。