Этот вопрос связан с веб-приложением ASP.NET core 2.2 (предназначенным для ядра .NET), в котором представлены некоторые реализованные контроллеры веб-API, использующие промежуточное ПО mvc.
Все методы действия, доступные во всех контроллерах, должны отвечать как http-методам GET, так и HEAD.
Мы заметили, что ядро ASP.NET автоматически добавляет заголовок Transfer-Encoding со значением chunked и, в соответствии со спецификациями, пропускает заголовок Content-Length (подробнее см. на этой странице MDN ). ).
В соответствии с этой проблемой github в основном репозитории ASP.NET кажется, что это поведение зависит от точного проектного решения веб-сервера Kestrel, так что это предполагаемое поведение.
Тем не менее, каждый раз, когда мы отправляем запрос HEAD на любой маршрут нашего приложения, мы получаем ответ с заголовком Content-Lenght, установленным в 0, даже когда соответствующий запрос GET (я имею в виду запрос GET с тем же путем) возвращает непустое тело ответа.
Согласно тому, что я читал в различных источниках, кажется, что заголовок Content-Lenght не является обязательным для ответа на запрос HEAD, но при включении он должен иметь то же значение, что и соответствующий запрос GET. Поэтому значение 0, которое мы видим в каждом запросе HEAD, мне не кажется правильным.
Является ли это побочным эффектом того факта, что для соответствующего запроса GET ядро ASP.NET отправляет ответ с помощью кусков (как описано выше, Transfer-Encoding всегда chunked для запросов GET)?
Еще одно сомнение связано с тем, что кеш любого типа отправляет запросы HEAD нашему приложению, чтобы решить, очищать или нет кэшированный ответ: представляет ли Content-Lenght с нулевым значением риск для правильности поведения кэширования?
РЕДАКТИРОВАНИЕ 27 МАРТА 2018
Мы повторили наши тесты и получили разные, но более значимые результаты. Я могу подтвердить, что запросы GET и HEAD не отправляют заголовок Content-Length. Это определенно имеет смысл в соответствии с тем фактом, что тело ответа всегда передается клиенту, как описано выше.
Тем не менее, я думаю, что поведение ядра ASP.NET определенно имеет смысл для меня