在 HEAD 响应中避免 Content-Length答案

【问题标题】：Avoiding Content-Length in HEAD response在 HEAD 响应中避免 Content-Length
【发布时间】：2015-03-08 05:33:29
【问题描述】：

对于仅 HEAD 请求（例如，在处理动态生成的资源时）生成 Content-Length 响应标头的成本通常很高，但在完成生成 GET 响应主体所需的工作之后可能基本上是“免费的”。

当响应 GET 请求时提供 Content-Length（而不是分块响应）是合理的，但计算相应 HEAD 请求的 Content-Length 不合理或缓慢时，是否允许 HEAD 响应到：

完全省略 Content-Length 标头？
使用 Transfer-Encoding: chunked 进行响应，即使 GET 响应包含 Content-Length？

relevant W3C specification 表示 HEAD 请求“应该”（非“必须”）以相同的标头响应；是在 GET 响应中使用 Content-Length 的清洁度和总传输大小节省，在 HEAD 的情况下值得违反上述“应该”，或者是让两个响应都发送 Transfer-Encoding: chunked 的唯一合理选择标题？

【问题讨论】：

W3C 规范通常不考虑计算或其他资源限制。现实世界没有那么宽容。 IMO，可以打破规范以便为最终用户提供更好的体验。

标签： http http-headers

【解决方案1】：

感谢@julian-reschke 的提示，rfc-7231 表示：

服务器应该发送相同的头字段来响应 HEAD 请求，因为如果请求是 GET 则它会发送，除了可以省略有效负载头字段（第 3.3 节）。

根据同一文档的section 3.3，有效负载标头字段包括：

内容长度
内容范围
预告片
传输编码

【讨论】：