这个问题与一个 ASP.NET 核心 2.2 Web 应用程序（以 .NET 核心为目标）有关，该应用程序公开了一些使用 mvc 中间件实现的 Web api 控制器。所有控制器中可用的所有操作方法都必须响应 GET 和 HEAD http 方法。
我们注意到 ASP.NET 核心会自动添加Transfer-Encoding带有值的标头，chunked并根据规范省略Content-Length标头（有关更多详细信息，请参阅此 MDN 页面）。
根据ASP.NET 核心存储库上的这个 github 问题，这种行为似乎取决于 Kestrel Web 服务器的精确设计决策，因此这是预期的行为。
也就是说，每次我们向应用程序的任何路由发出 HEAD 请求时，我们都会得到一个将Content-Length标头设置为 0 的响应，即使相应的 GET 请求（我的意思是具有相同路径的 GET 请求）返回一个非空响应体.
根据我在各种来源上阅读的内容，似乎Content-Length对于 HEAD 请求的响应，标头不是强制性的，但是当包含它时，它应该与相应的 GET 请求具有相同的值。所以0我们在每个 HEAD 请求上看到的值对我来说似乎并不正确。
对于相应的 GET 请求，ASP.NET 核心通过使用块发送响应（如上所述Transfer-Encoding总是chunked针对 GET 请求），这是一个副作用吗？
另一个疑问与向我们的应用程序发出 HEAD 请求以决定是否清除缓存响应的任何类型的缓存有关：零值 Content-Length 是否会对缓存行为的正确性造成风险？
2018 年 3 月 27 日编辑
我们重复了测试，得到了不同但更有意义的结果。我可以确认 GET 和 HEAD 请求都没有发送任何 Content-Length 标头。这绝对是有道理的，因为响应主体总是按块传输到客户端，如上所述。
也就是说，我认为 ASP.NET 核心行为对我来说绝对有意义。