Перейти на PRO

В чем разница между HTTP-методами HEAD и GET?

Тип вопроса: HTTP и веб-протоколы Вероятность: 10% Категория: QA Тестировщик

Ответ

Метод HEAD идентичен методу GET с одним ключевым отличием: сервер НЕ ДОЛЖЕН возвращать тело сообщения (тело ответа) в ответе.

Назначение HEAD

Метод используется для получения только метаинформации (заголовков) о ресурсе, что позволяет:

  1. Проверить существование и доступность ресурса (по коду статуса).
  2. Проверить валидность кеша (используя заголовки Last-Modified или ETag).
  3. Узнать размер ресурса (Content-Length) или его тип (Content-Type) без загрузки всего содержимого, экономя трафик и время.

Пример запроса и ответа

HEAD /api/user/123 HTTP/1.1
Host: example.com

Ответ сервера (без тела):

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 256
Last-Modified: Wed, 21 Oct 2024 10:00:00 GMT
ETag: "abc123"

Важные особенности

  • Сервер должен возвращать для HEAD те же заголовки, что и для эквивалентного запроса GET.
  • Не все серверы или API могут корректно реализовать HEAD, поэтому иногда его эмулируют с помощью GET с последующим отбрасыванием тела.

Ответ 18+ 🔞

Да ты посмотри, какой хитрый метод придумали! HEAD, блядь. Ну типа GET, но... без тела, нахуй!

Представь ситуацию: тебе надо узнать про файл — а он там, сука, гигабайтный. Тыкаешь GET — и ждёшь, пока эта туша скачается, только чтобы понять, что он не изменился с прошлого раза. Полный пиздец, трафик в помойку, время на ветер.

А тут — HEAD, ёпта! Ты как бы спрашиваешь: «Эй, сервак, а файл-то живой?». А он тебе в ответ: «Живой, мудила, 200 OK. Весит столько-то, поменялся тогда-то, вот тебе ETag, не еби мозг». И ВСЁ! Тела-то никакого нет! Чистая метаинформация, как паспорт у ресурса. Гениально же, блядь!

Зачем это, спросишь? Да элементарно:

  1. Существует ли вообще эта хуйня? Отправил HEAD — получил 404. Всё, даже качать не пытаешься, не тратишь силы.
  2. А не обновился ли? У тебя в кеше старая версия. Ты шлёшь HEAD, смотришь на Last-Modified или ETag. Если совпало с твоим — сиди дальше, не грузи одно и то же, умник.
  3. А сколько весит-то, зараза? Заголовок Content-Length тебе всё расскажет. Решишь потом, стоит ли этот слоник тебе в кеш лезть.

Смотри, как это выглядит:

Ты шлёшь запрос, сука, почти как GET, но метод другой:

HEAD /api/user/123 HTTP/1.1
Host: example.com

А сервер тебе, такой хитрожопый, отвечает:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 256
Last-Modified: Wed, 21 Oct 2024 10:00:00 GMT
ETag: "abc123"

И всё! Точка. После заголовков — тишина, пиздец. Тела ответа нет, пустота. Но вся нужная инфа — вот она, в шапке.

Но есть, блядь, подводный камень, ядрёна вошь! По стандарту, заголовки в ответе на HEAD должны быть ТОЧЬ-В-ТОЧЬ такие же, как если бы ты запросил GET. А то некоторые криворукие разработчики, блядь, могут накосячить и отправить разное. И тогда твоя логика кеширования накроется медным тазом.

А ещё бывает, что сервер или API этот самый HEAD не поддерживают внатуре. Что делают умные люди? Эмулируют, сука! Шлют GET, получают ответ, считывают только заголовки, а тело — нахуй, в игнор. Костыль, но работает.

Вот такой вот полезный, ебать, метод. Казалось бы — мелочь, а экономит нервы, трафик и время. Не гонять же по сети то, что тебе не нужно, правда?

© ХакСобесов, 2026
support@hacksobesov.com