Transfer-Encoding

사용법

Transfer-Encoding 헤더는 현재 커넥션 구간에서 메시지 본문이 어떻게 인코딩되었는지 기술하는 홉 단위 헤더입니다. 각 중간 노드(프록시, 게이트웨이)는 전송 인코딩을 디코딩하고 메시지를 처리한 뒤, 다음 노드로 전달하기 전에 다시 인코딩합니다.

가장 흔한 값은 chunked로, 전체 Content-Length를 알기 전에 서버가 응답 스트리밍을 시작할 수 있게 합니다. 서버는 본문을 청크로 나누고 각 청크 앞에 크기 표시자를 붙입니다. 길이가 0인 청크는 메시지의 끝을 알립니다.

리소스 자체에 종단 간 압축을 적용하는 Content-Encoding과 달리, Transfer-Encoding은 인접한 두 노드 사이에서만 동작합니다. gzip으로 압축된 리소스를 chunked 커넥션으로 보내는 서버는 압축에 Content-Encoding을, 청크 분할에 Transfer-Encoding을 사용합니다.

HTTP HEAD 요청에 대한 응답에 Transfer-Encoding이 나타나면, 그 값은 대응하는 GET 응답에서 서버가 본문에 적용할 인코딩을 반영합니다.

참고

Content-Encoding은 종단 간입니다. 리소스 자체가 압축되고(예: gzip) 모든 수신자가 페이로드를 디코딩합니다. Transfer-Encoding은 홉 단위입니다. 인접한 두 노드 사이의 전송을 위해 적용되고 각 홉에서 제거됩니다. 하나의 응답이 두 헤더를 동시에 담을 수 있으며, 이때 Content-Encoding은 리소스 압축에, Transfer-Encoding은 chunked 전달에 쓰입니다.

참고

HTTP의 Transfer-Encoding 헤더는 이메일의 Content-Transfer-Encoding과 무관합니다. 후자는 이메일 본문에 쓰이는 base64나 quoted-printable 같은 MIME 인코딩을 다룹니다.

참고

Transfer-Encoding 헤더는 HTTP/2와 HTTP/3에서 금지됩니다. 이들 프로토콜은 자체 데이터 프레이밍 메커니즘을 제공하므로 전송 수준 인코딩이 불필요합니다.

chunked

chunked 디렉티브는 메시지 본문을 일련의 청크로 나눕니다. 각 청크는 16진수로 표기된 청크 크기로 시작하고 그 뒤에 청크 데이터가 옵니다. 크기가 0인 마지막 청크가 메시지를 종료합니다. Trailer 헤더는 마지막 청크 뒤에 덧붙는 필드를 나열합니다.

compress

compress 디렉티브는 Lempel-Ziv-Welch(LZW) 압축을 적용합니다. 이 인코딩은 현대적인 배포 환경에서 거의 쓰이지 않습니다.

deflate

deflate 디렉티브는 deflate 알고리즘을 사용하는 zlib 압축을 적용합니다.

gzip

gzip 디렉티브는 32비트 CRC 체크섬을 포함한 Lempel-Ziv 코딩(LZ77)을 적용합니다. 이는 gzip 파일 형식이 사용하는 것과 같은 알고리즘이며 HTTP 구현 전반에서 널리 지원됩니다.

예시

서버가 chunked 응답을 보냅니다. Content-Length 헤더가 없다는 것은 서버가 본문을 조각 단위로 스트리밍하고 있음을 나타냅니다.

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
\r\n

여러 전송 인코딩은 순서대로 적용됩니다. 이 응답에서 본문은 먼저 gzip으로 압축된 뒤 전송을 위해 청크로 나뉩니다.

Transfer-Encoding: gzip, chunked