Как используется HTTP метод HEAD
Что проверяют
Знаете ли вы HEAD глубже, чем «GET без тела», и умеете ли тестировать его как отдельный метод API. Следом обычно спрашивают, чем HEAD отличается от GET и OPTIONS и что делать, если сервер отвечает на HEAD иначе, чем на GET.
Как отвечать
По спецификации HTTP (RFC 9110) HEAD это тот же GET, только сервер не отправляет тело ответа. Статус и заголовки должны совпадать с теми, что пришли бы на GET. Метод безопасный и идемпотентный, ответ на него может кэшироваться.
Где применяется:
- проверка существования ресурса: 200 или 404 без скачивания страницы, так работают проверки битых ссылок и мониторинг;
- метаданные перед загрузкой:
Content-Length,Content-Type,Accept-Rangesподсказывают, стоит ли качать файл и можно ли докачивать его частями; - актуальность кэша: по
ETagиLast-Modifiedклиент понимает, изменился ли ресурс.
Как тестировать: в Postman выбрать метод HEAD, в терминале curl -I <url>. Что проверить в тест-кейсе:
- паритет с GET: тот же статус и те же ключевые заголовки на одном и том же URL;
- пустое тело: даже при 200 в ответе нет ни байта тела;
- негативные сценарии: 404 для несуществующего ресурса, 401 или 403 без авторизации, как у GET;
- неподдерживаемый метод: если HEAD не реализован, корректный ответ 405 с заголовком
Allow, а не 500.
Многие фреймворки обрабатывают HEAD автоматически для каждого GET-маршрута, поэтому расхождения чаще всплывают в самописных обработчиках и на прокси.
Где спотыкаются
Путают HEAD с OPTIONS. OPTIONS спрашивает, какие методы разрешены, и участвует в CORS preflight, а HEAD возвращает заголовки конкретного ресурса.
Пишут curl -X HEAD вместо curl -I. В первом случае curl ждёт тело по объявленной длине и висит до таймаута, а флаг -I отправляет HEAD и тела не ждёт.
Считают, что HEAD экономит ресурсы сервера. Экономится только передача: обработчик часто выполняет всю работу GET, включая запросы к базе, и просто отбрасывает тело. Поэтому HEAD не заменяет лёгкий эндпоинт для health check.