ASP.NET core：HTTP HEAD 请求和 Content-Length 标头

这个问题与 ASP.NET core 2.2 Web 应用程序（针对 .NET core）相关，该应用程序公开了一些使用 mvc 中间件实现的 Web api 控制器。所有控制器中可用的所有操作方法都必须响应 GET 和 HEAD http 方法。

我们注意到 ASP.NET Core 自动添加Transfer-Encoding带有值的标头chunked，并根据规范省略标Content-Length头（有关更多详细信息，请参阅此 MDN 页面）。

根据ASP.NET core 存储库上的这个 github 问题，这种行为似乎取决于 Kestrel Web 服务器的精确设计决策，因此这是预期的行为。

也就是说，每次我们向应用程序的任何路由发出 HEAD 请求时，Content-Length即使相应的 GET 请求（我的意思是具有相同路径的 GET 请求）返回非空响应正文，我们也会得到标头设置为 0 的响应。

根据我在各种来源上读到的内容，似乎Content-Length标头对于 HEAD 请求的响应不是必需的，但当包含标头时，它应该具有与相应 GET 请求相同的值。因此，我们在每个 HEAD 请求上看到的值0对我来说似乎不正确。

Transfer-Encoding对于相应的 GET 请求，ASP.NET Core 通过使用块发送响应（如上所述，总是chunked针对 GET 请求），这是否是事实的副作用？

另一个疑问与向我们的应用程序发出 HEAD 请求的任何类型的缓存有关，以便决定是否清除缓存的响应：零值 Content-Length 是否会对缓存行为的正确性带来风险？

2018 年 3 月 27 日编辑

我们重复了测试，得到了不同但更有意义的结果。我可以确认 GET 和 HEAD 请求都没有发送任何 Content-Length 标头。根据如上所述响应正文总是按块传输到客户端的事实，这绝对是有意义的。

也就是说，我认为 ASP.NET Core 行为对我来说绝对有意义。