Trailer
요청·응답 General

개요

Trailer는 청크 전송(Transfer-Encoding: chunked)에서 본문 뒤에 이어질 후행 헤더(트레일러)들의 이름을 미리 알리는 헤더입니다. 수신자는 이 목록을 보고 본문 끝의 트레일러를 기대·처리합니다.

값은 트레일러로 전송될 헤더 이름의 목록입니다(예: `Trailer: Expires, Content-Digest`). 실제 트레일러 헤더 값 자체는 청크 스트림의 끝에 도착합니다.

자세히

트레일러의 존재 이유는 '본문을 다 만들어야 값을 알 수 있는 헤더'를 다루기 위함입니다. 응답을 스트리밍으로 흘려보내면서 시작 시점에는 알 수 없는 값(전체 본문의 무결성 해시, 서명, 최종 처리 상태 등)을 본문 뒤 트레일러로 붙일 수 있습니다. 이렇게 하면 서버가 응답을 버퍼링해 길이를 미리 계산하지 않고도 스트리밍할 수 있습니다.

동작에는 세 조각이 맞물립니다. 전송은 Transfer-Encoding: chunked여야 하고, 서버는 Trailer 헤더로 어떤 트레일러가 올지 예고하며, 클라이언트는 `TE: trailers`로 이를 받아들이겠다고 밝혀야 합니다. Content-Length·Transfer-Encoding·Content-Encoding·Host처럼 프레이밍·라우팅에 관여하는 헤더는 트레일러로 보낼 수 없습니다(스트림을 해석하기 전에 필요하기 때문).

많은 HTTP/1.1 클라이언트·프록시가 트레일러를 무시하거나 제거하므로, 트레일러에는 반드시 필요한 필수 정보가 아니라 '있으면 좋은' 부가 정보만 담는 것이 안전합니다. HTTP/2·HTTP/3에서는 청크 코딩 대신 프레임 기반으로 트레일러(트레일링 HEADERS 프레임)를 전송하지만, 개념은 동일합니다. gRPC가 상태 코드를 트레일러로 싣는 대표적 사례입니다.

문법

Trailer: <header-name>[, <header-name>]*

e.g. Trailer: Expires, Content-Digest

실무 참고

관련 헤더

스펙 근거