当两个服务器对同一段请求产生不同理解——HTTP Request Smuggling
想象一个场景：前端反向代理和后端应用服务器各自独立解析 HTTP 请求，但对请求边界的判断不一致。攻击者精心构造一段数据，让代理认为是一个请求，后端却读成两个。这就是 HTTP Request Smuggling 的核心——利用中间链路上的解析差异，把恶意载荷"走私"进后端。
最经典的场景是 CL-CL（Content-Length 对 Content-Length）和 CL-TE（Content-Length 对 Transfer-Encoding）之争。当前端用
实战中这类漏洞的危害远不止理论上的"请求解析差异"。因为它发生在协议层，可以绕 WAF、劫持他人会话、投毒缓存，甚至在前端把管理员的请求"拼接"到攻击者控制的内容上完成 CSRF。2019 年 James Kettle 的研究把这类攻击带入了主流视野，后来各大厂商的修复反而又引入了新的变体——比如 TE-CL、TE-TE，甚至 H2._.Smuggle（利用 HTTP/2 降级到 HTTP/1.1 的转换差异）。
防御的关键在于： 下次你看到一个反向代理后面挂着多层服务时，可以想想：它们对"请求从哪里开始、到哪里结束"这件事，真的达成一致了吗？
#Security
想象一个场景：前端反向代理和后端应用服务器各自独立解析 HTTP 请求，但对请求边界的判断不一致。攻击者精心构造一段数据，让代理认为是一个请求，后端却读成两个。这就是 HTTP Request Smuggling 的核心——利用中间链路上的解析差异，把恶意载荷"走私"进后端。
最经典的场景是 CL-CL（Content-Length 对 Content-Length）和 CL-TE（Content-Length 对 Transfer-Encoding）之争。当前端用
Content-Length: 100 截断请求体，后端却优先看 Transfer-Encoding: chunked，一段被前端忽略的残余数据就会被后端当作下一个请求的开头。攻击者可以把完整的恶意请求藏在前一个请求的"影子"里，绕过前端的访问控制和安全校验。实战中这类漏洞的危害远不止理论上的"请求解析差异"。因为它发生在协议层，可以绕 WAF、劫持他人会话、投毒缓存，甚至在前端把管理员的请求"拼接"到攻击者控制的内容上完成 CSRF。2019 年 James Kettle 的研究把这类攻击带入了主流视野，后来各大厂商的修复反而又引入了新的变体——比如 TE-CL、TE-TE，甚至 H2._.Smuggle（利用 HTTP/2 降级到 HTTP/1.1 的转换差异）。
防御的关键在于： 下次你看到一个反向代理后面挂着多层服务时，可以想想：它们对"请求从哪里开始、到哪里结束"这件事，真的达成一致了吗？
#Security
