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