개요

Content-Encoding은 본문에 실제로 적용된 압축·변환 방식을 나타내는 헤더입니다. 수신 측은 이 값을 보고 본문을 원래대로 복원(해제)한 뒤 Content-Type에 따라 해석합니다.

자세히

가장 흔히 응답에서 쓰이며, 서버가 클라이언트의 Accept-Encoding 선호를 받아 gzip·br 등으로 압축한 뒤 실제 사용한 코딩을 이 헤더로 알립니다. 여러 코딩이 순차 적용되면 적용된 순서대로 나열합니다(수신 측은 역순으로 해제). 이는 종단 간(end-to-end) 변환이라 최종 수신자까지 유지됩니다.

중요한 점은 Content-Length가 압축 후(인코딩 적용 후) 바이트 수를 가리킨다는 것입니다. 즉 Content-Encoding으로 압축된 응답의 Content-Length는 압축된 크기입니다. 반대로 Content-Type은 압축을 벗겨낸 원본의 타입을 나타냅니다.

홉 단위(hop-by-hop)로 전송 구간에서만 적용됐다 벗겨지는 Transfer-Encoding과 달리, Content-Encoding은 리소스 표현 자체의 일부로 취급됩니다. 그래서 ETag·캐시는 인코딩된 표현을 기준으로 하며, `Vary: Accept-Encoding`이 필요합니다.

문법

Content-Encoding: <coding>[, <coding>]*

e.g. Content-Encoding: gzip

지시어 / 값

실무 참고

• 이미 압축된 형식(JPEG·PNG·zip·mp4)에 gzip을 다시 적용하면 크기가 오히려 커질 수 있습니다.
• 요청 본문에도 Content-Encoding을 쓸 수 있지만, 서버가 지원하지 않으면 415로 거부될 수 있습니다.
• HTTPS와 결합 시 압축은 BREACH 공격 표면을 만들 수 있으니 비밀 값 처리에 주의하세요.
• Transfer-Encoding(홉 단위)과 혼동 금지 — 목적과 캐시 취급이 다릅니다.

관련 헤더

관련 상태코드

스펙 근거