如何解读ElasticSearch HEAD响应中Transfer-Encoding: chunked的合规性问题？

1. RFC 9112的两处核心规定 #

• HEAD响应的限制与Transfer-Encoding的特殊许可：RFC 9112明确要求HEAD请求的响应绝对不能包含消息体，但允许携带Transfer-Encoding头字段。这个字段的作用是告知客户端：如果发起对应的无条件GET请求，源服务器会对响应体应用该传输编码。不过这个指示是可选的，链路中的任何节点（包括源服务器自己）都可以在不需要时移除这个编码头。
• chunked编码的强制格式要求：同一RFC的7.1节规定，使用chunked传输编码的响应，必须包含块大小标识（chunk-size），而chunk-size属于消息体的组成部分。

2. ElasticSearch的违规行为与HAProxy问题根源 #

ElasticSearch在处理HEAD请求时，返回了Transfer-Encoding: chunked头字段，但没有发送对应的chunk-size（也就是完全没有消息体相关的块内容）。HAProxy严格遵循chunked编码的规范，认为缺少chunk-size的响应是非法的，因此触发了兼容性错误。

3. 结论：ElasticSearch的行为不符合RFC规范逻辑 #

这里的核心矛盾在于：RFC允许HEAD响应带Transfer-Encoding，但如果编码类型是chunked，就必须满足chunked的格式要求（携带chunk-size），可HEAD响应又被禁止包含消息体（chunk-size属于消息体部分）。这本质上意味着HEAD响应根本不应该使用Transfer-Encoding: chunked，因为这会陷入“允许带编码头但又无法满足编码格式要求”的逻辑死胡同。

ElasticSearch的做法明显违反了RFC的隐含逻辑：既然HEAD响应不能有消息体，就不该使用依赖消息体部分（chunk-size）的chunked编码。正确的处理方式是不在HEAD响应中返回Transfer-Encoding: chunked，这才是符合RFC规范的选择。

内容的提问来源于stack exchange，提问作者Jiri Pencak