gzip은 원래 파일 종류가 아니라 적용한 인코딩일 수 있습니다
Content-Encoding은 자원에 적용한 인코딩과 순서를 설명하며 수신자가 원래 형식으로 되돌리는 데 사용합니다. Content-Type: text/html과 Content-Encoding: gzip이면 원래 표현은 HTML이고 전송용 인코딩에 gzip을 썼다는 뜻입니다. 근거: MDN Content-Encoding, 2026-11-04.
근거: MDN Content-Encoding · 2026-11-04 확인
ZIP 파일 자체와 HTTP 압축은 다른 층입니다
사용자가 ZIP 파일을 받는 경우 그 파일이 이미 압축된 형식이라는 사실을 무조건 Content-Encoding에 적는 것은 아닙니다. 반대로 HTML을 HTTP 압축했다고 ZIP 파일로 변환했다고 설명하지 않습니다. 가상의 원문 크기와 전송 크기를 비교할 때도 압축 전·후 어느 값을 적었는지 표시합니다. 여기서는 실제 크기를 측정하지 않았으므로 절감 비율을 제시하지 않습니다.
근거: MDN Content-Encoding · 2026-11-04 확인
해독 오류라면 헤더와 실제 바이트를 대조합니다
허가된 응답의 상태·Content-Type·Content-Encoding과 요청의 지원 인코딩을 기록합니다. 서버가 gzip이라고 선언했는데 실제로는 압축하지 않았거나 이미 해독한 데이터를 다시 해독하려 하면 문제가 될 수 있습니다. 브라우저·HTTP 라이브러리가 자동 해독하는지 공식 문서에서 확인하고 같은 데이터를 무작정 여러 번 풀지 않습니다. 실제 원인이 확정되지 않았다면 헤더 오류라고 단정하지 않습니다.
근거: MDN Content-Encoding · 2026-11-04 확인
연속 인코딩은 적용 순서와 해제 순서를 나눕니다
여러 인코딩이 표시되면 목록은 적용한 순서라는 점을 확인합니다. 수신자가 원문으로 되돌릴 때 어떤 단계에서 실패했는지 기록해야 압축 파일 손상과 프로토콜 처리를 구분할 수 있습니다. 서버나 중간 프록시가 내용을 바꿨다면 대응하는 헤더도 맞는지 담당자가 확인할 항목입니다. 운영 압축 설정을 임의로 끄는 방식부터 시도하지 않습니다.
성공은 원문 형식으로 읽히고 내용이 맞는 상태입니다
압축 오류가 사라진 뒤 원래 미디어 형식으로 열고 핵심 내용이 기대와 맞는지 봅니다. 전송 크기가 줄었다는 사실만으로 이미지 품질이나 페이지 동작까지 보장하지 않습니다. 이미 압축된 ZIP·JPEG를 다시 압축해도 항상 더 작아지는 것은 아니므로 성능 판단은 실제 조건에서 측정한 값으로만 합니다.
원문으로 이어 읽기
확인일: 2026-11-04. 정의와 적용 범위, 발행일과 판본을 함께 살펴봅니다. 원문이 존재한다는 사실만으로 개별 주장의 정확성과 재사용 권리가 자동 보장되지는 않습니다.