http - HTTP代理应如何处理HEAD请求？

RFC7230中所述的HTTP / 1.1协议是无状态的，但是HEAD请求方法应该在客户端和代理中生成一些状态，因为没有其他方法可以确定对HEAD请求的响应的消息主体的长度。

只有几种方法可以确定HTTP响应的实际传输长度。它们在RFC7230的3.3.3中描述。

让我们假设HTTP请求处理已在进行中，并且客户端向原始服务器上的某些现有资源生成了HEAD和GET的有效序列，并且从客户端到原始服务器的路径上存在透明的HTTP代理。

HTTP协议被定义为无状态，因此，在通信的任何部分或协议本身采取的任何操作都不会生成任何状态（不是必须生成某些状态（如TCP来对消息进行重新排序等）的传输协议）。

如果代理必须记住该请求已经完成的事实，那么代理应该如何识别对客户端HEAD请求的源服务器响应的结束（即消息正文的长度）？

如果代理盲目解释源服务器响应HEAD方法发送的Content-Length或Transfer-Encoding字段，则只要源服务器永远不会发送消息主体，代理就会无限期地等待消息主体。

因此，客户端必须生成一些状态以记住不是发送GET而是发送了HEAD请求（由于相同的问题-无法确定消息正文长度）。

因此，HEAD方法本质上是无状态HTTP协议中的有状态方法，这是一个矛盾。

更糟糕的是，HEAD方法必须由RFC7231中的4.1所述的任何服务器实现，并且不能用501或405进行响应。

此矛盾使得可以在HTTP代理上实现简单的攻击媒介：将HEAD请求与代理混合，以生成足够的状态以产生内存不足错误。

我所做的一项小型研究表明，现代代理将HEAD请求交换为GET请求，但是与简单记住资源路径和请求类型（例如，在某些哈希图中）相比，这将产生更多的状态和流量。

因此，我可以得出结论，HEAD请求的存在与HTTP / 1.1协议的无状态性相矛盾。