http请求转发那些事：你可能不知道的hop-4008云顶国际网站

引子

最近看到f5官方发布的公告，给出了一个身份验证绕过漏洞（cve-2022-1388）的修复方案。这个漏洞允许攻击者发送一些未公开的请求，来绕过身份认证，进而控制系统。通过阅读4008云顶国际集团官网的，发现这个漏洞的修复居然和http请求头的不当使用有关（如下图所示）。而在请求转发时如果没有妥善处理图中“connection:close”这样的请求头，可能会导致请求频繁失败。今天就来简单聊聊容易让请求转发出问题的hop-by-hop headers。

请求转发中的http header

目前，微服务成为一种流行的webapp部署模式，部署时多个微服务之间难免进行数据交互。考虑下列请求转发场景，这里app a可能是一个自己编写的鉴权服务器或者代理服务器：

app a将一个请求，原封不动地转发给了app b，并且将app b的响应原封不动地返回给客户端。如果app a的代码或者web容器没有对app b的响应头做特殊处理，就容易出现上述情况：响应头中包含了两个key值一样的header：connection：somevalue。

由于响应头中connection字段决定了http的长连接是否可用， 当样例中的两个connection字段值不同时，客户端收到请求后无法明确辨析服务端对当前http连接的态度，会导致一些不可预知的情况。例如，如果valuea是“close”，而valueb是“keep-alive”，这个时候客户端无法清晰的知道服务端是否会继续维系当前http连接。

在中，对响应头划分为了end-to-end headers和hop-by-hop headers，hop-by-hop headers往往会影响客户端对http响应的连接维系、内容处理策略等，connection字段就是rfc 2612所定义的一个hop-by-hop headers。

如图，rfc 2612给出了http/1.1中的响应头，并解释hop-by-hop headers：hop-by-hop headers中的响应头，对一次连接有意义，然而，这些响应头不应该被缓存或者层层转发。反过来理解，也就是层层转发以上响应头，请求可能会出问题。

一个transfer-encoding被转发的例子：

如图，当app b存在分块响应时，transfer-encoding响应头会提醒app a进行分块读取。具体来说，app b的响应体中包含了transfer-encoding：chunked，app a发现这个响应头后，在读取响应体时，会读取若干个响应分块，对每个分块，会先读取一个分块大小，而后读取分块。当app a将transfer-encoding：chunked携带回客户端时，客户端会试图按理解分块响应的操作对app a的响应进行读取，然而，使用curl会打印这样的信息，这说明app a没有对响应内容做了分块：

当app a和 app b的容器为tomcat或者spring boot时，容易复现此场景，app a使用jetty作为容器则不易复现此问题。这说明部分web容器对hop-by-hop headers的处理策略是不同的。

总结

不是所有的web容器都能帮助开发者屏蔽hop-by-hop headers，有些容器反而允许开发者自定义hop-by-hop headers来实现更大程度的灵活性。

在处理请求转发场景时，开发者面对这样的header要分外小心，尽量显示使用或者显示屏蔽这些header，在更换web容器时需要进行必要的测试。

参考资料

[1]f5公告的漏洞：

[2]abusing http hop-by-hop request headers: 

[3]rfc 2612: