为什么 curl 发送 Proxy-Connection header,即使 RFC 似乎不鼓励这样做?

Why does curl send a Proxy-Connection header, even though the RFC seems to discourage it?

RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing states in the appendix:

As a result, clients are encouraged not to send the Proxy-Connection header field in any requests.

为什么 curl 发送这个 header 然后,当使用代理时?

$ http_proxy=0.0.0.0:8080 curl -v http://google.com
...
> Accept: */*
> Referer:
> Proxy-Connection: Keep-Alive
>
...

我在 x86_64-pc-linux-gnu 上使用 curl 7.71.1


附录:这是另一个协议,但 HTTP/2 明确禁止 Connection 和相关字段,根据 RFC 7540 Section 8.1.2.2

多么棒的问题!谢谢提问。

这是网络上的一个例子,其中规范和我们应该做的事情与现实不符,如果我们尝试遵循这些规范会发生什么书面指南!

早在 2016 年,我们(在 curl 项目中)实际上从对代理所做的 curl 请求中删除了 Proxy-Connection: Keep-Alive header 正是出于这个原因:没有必要,因为协议暗示 keep-alive 规范是这么说的!

然后(在那次更改之后)我们立即从那些代理连接完全中断并且持久连接根本无法工作的人那里得到了一系列错误报告...一旦我们恢复了更改,一切都恢复正常了。

因此,也许在 2026 年左右,情况已经发生了足够大的变化,因此我们可以 运行 再次进行该实验。在那之前,我们将 header 保留在代理请求中,这样所有那些正在使用的糟糕的遗留代理就不会发疯了!

世界野生网络是一个疯狂的地方。

只是作为解决方法的注释,

我发现我的代理正在转发 Proxy-Connection header,并且出于某种原因,如果 Web 服务器看到 header,它会返回 403。设法删除 header 与:

curl -v -x proxyserver --proxy-header "Proxy-Connection:" http://example.com