Varnish Cache中bereq.body与Content-Length的关联机制解析

问题背景

在Varnish Cache 7.5.0版本中，当使用unset bereq.body指令时，如果请求体已被消费，系统不会自动移除对应的Content-Length头部。这一行为在特定场景下会导致后端服务器（如Tomcat）处理异常，特别是在需要执行多次后端请求（如先HEAD后GET）的业务逻辑中。

技术原理

Varnish处理HTTP请求时，请求体(body)与相关头部(如Content-Length)存在强关联。核心机制体现在：

1. 对象引用机制：bereq_body通过HSH_DerefObjCore进行引用计数管理
2. 头部同步逻辑：原始实现中，Content-Length的清除与bereq_body的释放绑定在一起
3. 请求生命周期：在请求重启(restart)或回滚(rollback)时，相关资源需要重新初始化

问题根源

通过分析源码发现，当满足以下条件时会出现问题：

1. 客户端发送带有body的GET请求
2. VCL执行unset bereq.body
3. 请求被重启（如先HEAD后GET）
4. 第二次请求时bereq_body已为NULL，但Content-Length头部未被清除

根本原因是清除Content-Length的逻辑仅当bereq_body非NULL时执行，而重启后该条件不再满足。

解决方案演进

开发团队经过多次讨论后确定了最佳修复方案：

1. 初始方案：在vbf_stp_startfetch阶段添加条件判断
2. 优化方案：恢复在VRT_u_bereq_body中的http_Unset调用
3. 完整方案：同时处理Content-Length和Transfer-Encoding头部

关键修复点包括：

• 确保unset bereq.body后相关头部同步清除
• 增加对请求重启场景的处理
• 保持与现有rollback机制的一致性

最佳实践建议

对于需要处理类似场景的用户，建议：

1. 明确业务是否需要请求体
2. 如需清除body，应在VCL早期阶段执行
3. 检查后端服务对不一致头部的容忍度
4. 考虑升级到包含修复的版本

延伸思考

这个问题揭示了HTTP中间件中请求体处理的复杂性，特别是：

• 请求体重用时的状态管理
• 头部与实体的同步机制
• 多次请求间的上下文传递

这些设计考量对构建可靠的缓存服务至关重要，也体现了Varnish在HTTP协议处理上的严谨性。