Apache TrafficServer 缓存刷新时丢失 Content-Type 头的故障分析

问题现象

在 Apache TrafficServer 9.2.5 版本中，当处理包含重复头字段的 HTTP 响应时，系统在缓存刷新阶段（TCP_REFRESH_HIT/200）会出现 Content-Type 响应头丢失的情况。具体表现为：

1. 首次请求（TCP_MISS/200）时，所有响应头（包括重复头字段）都能正确返回
2. 当缓存过期后触发刷新请求时：
   • 若源站返回 304 Not Modified 响应
   • 且响应中包含重复头字段（如示例中的 X-Reveal-Duplicate）
   • 则 TrafficServer 返回给客户端的响应中会丢失 Content-Type 头

技术背景

HTTP 协议允许服务器在响应中发送重复的头部字段，这在 RFC 7230 中有明确定义。常见的重复头部场景包括：

• Set-Cookie 头
• Cache-Control 头的多值情况
• 自定义的 X- 头部

TrafficServer 在处理缓存刷新时，会向源站发送条件请求（If-Modified-Since），并根据源站的 304 响应来更新缓存条目。这个过程中需要正确处理所有头部字段的合并与更新。

问题根源分析

通过调试日志分析，发现问题出在 TrafficServer 的头部合并逻辑中：

1. 当源站返回 304 响应时，系统会尝试将新响应头与缓存中的旧头合并
2. 在存在重复头字段的情况下，合并算法可能错误地跳过了 Content-Type 头的复制
3. 特别是当重复头的值不相同时（如 X-Reveal-Duplicate: same 和 X-Reveal-Duplicate: other），问题更容易触发

影响范围

该缺陷会影响以下场景：

• 使用 TrafficServer 作为反向代理缓存
• 源站响应中包含重复的头部字段
• 内容类型依赖 Content-Type 头的应用（如 Web 应用、API 服务）
• 使用条件缓存验证（If-Modified-Since）的场景

解决方案

该问题已在后续版本中修复，主要改进包括：

1. 重写了头部合并逻辑，确保在 304 响应处理时保留所有必要的头字段
2. 特别处理了 Content-Type 等关键头部的复制
3. 优化了重复头字段的处理流程

对于仍在使用受影响版本的用户，建议采取以下临时解决方案：

1. 在源站避免发送重复的头部字段
2. 通过配置强制 TrafficServer 忽略特定的重复头
3. 升级到已修复该问题的版本

最佳实践建议

为避免类似问题，建议在 TrafficServer 部署中：

1. 定期检查源站的响应头规范
2. 对关键头字段（如 Content-Type）实施监控
3. 在测试环境中验证缓存刷新行为
4. 保持 TrafficServer 版本更新

该案例展示了 HTTP 缓存实现中头部处理的复杂性，特别是在处理非标准响应时的边界情况。开发者在实现缓存逻辑时需要特别注意头部字段的完整性和一致性。