HEAD

사용법

HEAD 요청은 리소스에 대한 메타데이터, 즉 크기, 타입, 신선도, 존재 여부를 가져옵니다. 서버는 요청을 GET과 정확히 동일하게 처리하되 본문을 전송하기 직전에 멈춥니다. Content-Length와 Content-Type을 포함한 모든 응답 헤더는 완전한 GET 응답의 것과 일치합니다.

흔한 사용 사례

링크 검증. 자동화 도구는 전체 페이지를 내려받지 않고도 URL이 200을 반환하는지 확인하기 위해 HEAD 요청을 보냅니다. 깨진 링크는 404나 410 응답으로 드러납니다.

모니터링과 헬스 체크. 가동 시간 모니터는 가용성을 확인하기 위해 HEAD로 엔드포인트를 탐색합니다. 응답 크기가 작아 대역폭이 절약되고 폴링 주기를 빠르게 가져갈 수 있습니다.

콘텐츠 협상 사전 확인. 클라이언트는 리소스 전체를 가져올지 결정하기 전에 Content-Type, Content-Encoding, Content-Language 헤더를 살펴봅니다.

캐시 검증. ETag나 Last-Modified를 담은 HEAD 응답은 캐시가 본문을 내려받지 않고도 신선도를 확인할 수 있게 해 줍니다. HEAD 응답 헤더가 캐시된 사본이 낡았음을 나타내면 캐시는 해당 항목을 그에 맞게 표시합니다.

다운로드 크기 추정. 파일 관리자와 다운로드 도구는 전송을 시작하기 전에 파일 크기를 표시하거나 디스크 공간을 확보하기 위해 HEAD 응답의 Content-Length를 읽습니다.

참고

HEAD 요청의 요청 본문에는 일반적으로 정의된 의미가 없습니다. 일부 구현은 본문을 담은 HEAD 요청을 거부합니다. 본문을 포함하면 메시지 프레이밍을 잘못 파싱하는 중계자에서 요청 스머글링 취약점을 유발할 위험이 있습니다.

예시

리소스가 존재하는지 확인하고 응답 헤더를 살펴보기 위한 HEAD 요청입니다. 서버는 콘텐츠 메타데이터와 함께 200을 반환하지만 본문은 없습니다.

요청

HEAD /report.pdf HTTP/1.1
Host: example.com

응답

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 284750
Last-Modified: Mon, 10 Feb 2025 08:30:00 GMT
ETag: "f47ac10b"

Content-Length 헤더는 그 파일이 대략 278 KB임을 알려 줍니다. Last-Modified와 ETag 헤더는 이후 요청에서 조건부 요청에 쓸 검증자를 제공합니다.

CORS

HEAD는 CORS 안전 목록에 포함된 메서드입니다. 교차 출처 HEAD 요청은 프리플라이트 요청을 유발하지 않으며, GET과 동일한 안전 목록 동작을 따릅니다.

HEAD와 GET 비교

HEAD는 GET과 같은 헤더를 반환하지만 응답 본문은 전부 생략합니다. 덕분에 메타데이터만 필요한 작업에서는 HEAD가 더 빠르고 대역폭 효율도 좋습니다.

흔한 활용으로는 리소스의 존재 확인, 파일 크기를 위한 Content-Length 읽기, Last-Modified 날짜 확인, 그리고 리소스 전체를 내려받지 않고 ETag 같은 캐시 검증자를 얻는 것이 있습니다.

일부 서버는 내부적으로 GET 핸들러를 전부 실행한 뒤 응답을 보내기 전에 본문을 잘라내는 방식으로 HEAD를 구현합니다. 그런 경우 성능 이득은 본문 바이트의 전송 시간을 아끼는 데 그칩니다.

HEAD 응답은 캐시된 GET 응답을 갱신하기도 합니다. 캐시가 HEAD 요청을 보냈고 반환된 검증자가 저장된 GET 항목과 일치하면, 캐시는 저장해 둔 헤더를 그에 맞게 갱신합니다.

SEO 영향

검색 크롤러는 HEAD가 아니라 GET으로 페이지를 가져오므로 HEAD가 색인을 이끌지는 않습니다. 다만 본문을 내려받지 않고 URL이 200을 반환하는지 확인하는 링크 검사기, 가동 시간 모니터, SEO 감사 도구에는 HEAD가 여전히 유용합니다.