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协议的无状态性相矛盾。
答案 0 :(得分：0)
RFC指出：
HTTP被定义为无状态协议，这意味着每个请求 消息可以孤立地理解。
这并不意味着服务器无法维持任何状态。这并不意味着服务器无法将请求数据保留在内存中，也无法保持有关TCP / IP连接或请求本身的状态-否则它将无法响应。
这只是意味着在不同的请求-响应对之间没有任何状态可以保留。