HTTP代理是否需要使用标头？

Question

HTTP代理是否可以忽略HTTP标头并盲目地传递它们？我正在寻找一个非常简单的前向代理，并希望最大限度地减少复杂性和攻击面。

Answer 1

在@Evert响应中添加更多内容。

代理应该尝试重写干净的HTTP语言。通常你不会改变身体，但是标题不一样。

您必须解析标头以检测一些对邮件正文大小有影响的特殊标头（如Content-Length或Transfer-Encoding）。所以你有一个解析版的标题。不要粘贴已接收标头的原始版本，从重新解析的版本重写它。所以应该应用这种转变：

#incoming   ：HeaderValue \ n   ：HeaderValue2 \ n   #out   ：HeaderValue，HeaderValue \ r \ n

协议版本（第一行结束）也是如此。反向代理必须强制执行该值（HTTP / 1.1或HTTP / 1.0），不要从请求中复制粘贴值。

然后在@Evert列出的rfc7230之后，你会发现很多MUST / MUST NOT代理，你也应该看看：

• rfc7231（很多事情，但请看 100-continue 问题）
• rfc7232（条件请求）
• rfc7233（范围请求）
• rfc7234（缓存 - 可能不适合你 - ）

您阅读的HTTP越多，编写简单代理就越难。

rfc中的大多数规则都是为了确保代理将说出一个不错的HTTP，清除糟糕或奇怪的HTTP语法，这对于HTTP走私攻击非常重要，这是一个代理的大问题。如果您的代理作为一种稍微不同的方式来解释几乎不错的HTTP语法，那么您最终可能会对消息进行错误的大小解释。

只有在HTTP KeepAlive上实现HTTP 管道传输时才会有危险。因此，如果您需要一个非常简单的转发代理，并且不确定HTTP语法清理，请确保代理上不支持管道（允许，服务器始终只能处理管道的第一个请求）：

• 添加Connection: close标题
• 仅处理第一个查询，只处理一个响应（如果您从后端收到多个响应）
• 收到后端响应后关闭后端tcp / ip连接，为每个请求创建一个新连接（没有后端保持连接）。

这不是拥有快速反向代理的方式，但这就是为什么编写一个好的，快速，强大的代理很难的原因。