This question is related to an ASP.NET core 2.2 web application (targeting .NET core) exposing some web api controllers implemented used the mvc middleware. All the action methods available in all the controllers must respond to both the GET and the HEAD http methods.
We noticed that ASP.NET core automatically add the Transfer-Encoding header with the value chunked and, according to the specifications, omits the Content-Length header (see this MDN page for more details).
According to this github issue on the ASP.NET core repository it seems that this behaviour depends on a precise design decision of the Kestrel web server, so this is the intended behaviour.
That said, each time we issue an HEAD request to any route of our application we get a response having the Content-Length header set to 0, even when the corresponding GET request (I mean a GET request having the same path) returns a non empty response body.
According to what I read on various sources, it seems that the Content-Length header is not mandatory for the response to an HEAD request, but when included it should have the same value as the corresponding GET request. So the value 0 that we see on each HEAD request does not seem correct to me.
Is it a side effect of the fact that, for the corresponding GET request, ASP.NET core sends the response by using chunks (as explained above Transfer-Encoding is always chunked for GET requests) ?
Another doubt is related to any kind of cache issuing HEAD requests to our application in order to decide whether or not to purge a cached response: does the zero-valued Content-Length pose a risk for the correctness of caching behaviour ?
EDIT OF 27th MARCH 2018
We repeated our tests and we got different but more meaningful results. I can confirm that both the GET and HEAD requests do not send any Content-Length header. This definitely makes sense according to the fact that the response body is always transmissed by chunks to the client as explained above.
That said I think that the ASP.NET core behaviour definitely makes sense to me.
