透明 HTTP 代理是否应该删除跃点 HTTP headers？
Should transparent HTTP proxy remove hop HTTP headers?
我读到 HTTP 代理应该删除跃点 HTTP headers (https://www.freesoft.org/CIE/RFC/2068/143.htm)
这是有道理的，因为其中一些 header 是 connection-related。
问题是。此 RFC 仅适用于显式代理还是应该也适用于透明 HTTP 代理？
只是给你举个例子。假设一个客户端执行 HTTP 调用并且它有一个显式代理集。但是，中间有一个透明代理。所以，整个管道看起来像这样
Client ↔ Transparent Proxy ↔ Explicit proxy ↔ Web page
显式代理可能需要身份验证并将发回 Proxy-Authenticate header。
如果透明代理删除此 header（根据 RFC），则不会提示客户端进行身份验证，任何操作都无效。
这个立即跳出，但我认为当透明代理看起来不应该触及 hop-by-hop headers 时，我认为可以设想其他一些场景。
我是不是遗漏了什么，或者 hop-by-hop 删除规则仅适用于显式代理？
透明代理不存在。
就HTTP RFC而言，根本就没有这回事。规范不承认这个概念。客户端 (A) 可以连接到服务器 (C) 以获取或修改资源，或者它可以连接到代理 (B) 以让后者代表它执行此操作。在前一种情况下，hop-by-hop headers 调节客户端和服务器之间的连接；在后者中，它们调节客户端和代理之间的连接。如果代理连接到服务器来处理请求，它必须为代理服务器管理自己的 hop-by-hop headers link.
除此之外你添加的任何其他内容都不是协议的一方，它的存在不应该影响它的运作方式。 (A) 与 (B) 或 (C) 的联系（或 (B) 与 (C) 的联系）是否由其他事物介导并不重要。重要的是，当 (A) 选择向 (B) 发送请求时，它应该收到与选择直接向 (C) 发出请求时相同的资源。 (B) 或 (C) 甚至不必是单一宿主；他们自己可以通过任意数量的中间层传递请求。
无论如何，“透明代理”也可能是一个 SOCKS 代理，在这种情况下它根本不会修改任何 HTTP headers，因为它甚至不能确定它是否转发了什么首先是HTTP。
我读到 HTTP 代理应该删除跃点 HTTP headers (https://www.freesoft.org/CIE/RFC/2068/143.htm)
这是有道理的，因为其中一些 header 是 connection-related。
问题是。此 RFC 仅适用于显式代理还是应该也适用于透明 HTTP 代理？
只是给你举个例子。假设一个客户端执行 HTTP 调用并且它有一个显式代理集。但是，中间有一个透明代理。所以，整个管道看起来像这样
Client ↔ Transparent Proxy ↔ Explicit proxy ↔ Web page
显式代理可能需要身份验证并将发回 Proxy-Authenticate header。
如果透明代理删除此 header（根据 RFC），则不会提示客户端进行身份验证，任何操作都无效。
这个立即跳出，但我认为当透明代理看起来不应该触及 hop-by-hop headers 时，我认为可以设想其他一些场景。
我是不是遗漏了什么，或者 hop-by-hop 删除规则仅适用于显式代理？
透明代理不存在。
就HTTP RFC而言，根本就没有这回事。规范不承认这个概念。客户端 (A) 可以连接到服务器 (C) 以获取或修改资源，或者它可以连接到代理 (B) 以让后者代表它执行此操作。在前一种情况下，hop-by-hop headers 调节客户端和服务器之间的连接；在后者中，它们调节客户端和代理之间的连接。如果代理连接到服务器来处理请求，它必须为代理服务器管理自己的 hop-by-hop headers link.
除此之外你添加的任何其他内容都不是协议的一方，它的存在不应该影响它的运作方式。 (A) 与 (B) 或 (C) 的联系（或 (B) 与 (C) 的联系）是否由其他事物介导并不重要。重要的是，当 (A) 选择向 (B) 发送请求时，它应该收到与选择直接向 (C) 发出请求时相同的资源。 (B) 或 (C) 甚至不必是单一宿主；他们自己可以通过任意数量的中间层传递请求。
无论如何，“透明代理”也可能是一个 SOCKS 代理，在这种情况下它根本不会修改任何 HTTP headers，因为它甚至不能确定它是否转发了什么首先是HTTP。