HTTP 헤더 (HTTP Header)

HTTP 헤더(HTTP Header)는 HTTP 요청이나 응답 메시지에 이름과 값의 쌍으로 실려 본문 밖의 부가 정보를 전하는 필드입니다. 클라이언트는 요청 헤더로 받고 싶은 데이터 형식이나 인증 정보를 알리고, 서버는 응답 헤더로 본문의 형식과 캐시 조건 같은 정보를 돌려줍니다. HTTP/1.x에서는 Content-Type: application/json처럼 이름, 콜론, 값을 한 줄에 씁니다.

이름과 값으로 이루어진 필드 구조

RFC 9110 HTTP 의미 규격은 헤더를 포함한 HTTP의 필드를 확장 가능한 이름과 값의 쌍으로 정의하고, 이 필드가 메시지의 헤더 섹션과 트레일러 섹션에 담긴다고 설명합니다. 메시지는 제어 데이터, 헤더 섹션, 본문 순서로 전송되고 본문 뒤에 트레일러 섹션이 붙을 수 있습니다. 같은 규격은 헤더 필드가 본문을 받기 전에 알아야 할 내용을, 트레일러 필드가 본문을 보내기 전에는 몰랐던 선택적 메타데이터를 담는다고 구분합니다.

필드 이름은 대소문자를 구분하지 않고, IANA의 HTTP 필드 이름 레지스트리에 등록하는 것이 권장됩니다. MDN의 HTTP 헤더 참조 문서에 따르면 HTTP/1.x에서는 이름 뒤에 콜론, 무시되는 선택적 공백, 값이 차례로 옵니다. HTTP/2 이상에서는 개발자 도구에 헤더 이름이 소문자로 표시되고, :status처럼 콜론으로 시작하는 의사 헤더(pseudo-header)라는 별도 묶음이 있습니다.

목록 문법을 허용하는 같은 이름의 필드가 여러 줄 오면, 받은 순서대로 쉼표로 이어 하나의 값으로 합칠 수 있습니다. RFC 9110은 Example-Field: Foo, Bar와 Example-Field: Baz 두 줄의 값을 Foo, Bar, Baz로 보는 예를 들고, 목록 문법을 쓰지 않아 합칠 수 없는 Set-Cookie는 예외로 다루라고 적었습니다. 알 수 없는 헤더는 Connection 헤더에 나열되거나 따로 막도록 설정된 경우가 아니면 프록시가 그대로 전달하고, 다른 수신자는 무시하도록 권장됩니다. 덕분에 무시해도 안전한 의미로 정의된 새 필드는 프로토콜 버전을 바꾸지 않고 추가할 수 있습니다.

요청·응답·표현 헤더와 본문의 구분

MDN의 HTTP 헤더 참조 문서는 헤더를 쓰이는 맥락에 따라 나눕니다. 요청 헤더는 가져올 리소스나 요청하는 클라이언트에 대한 정보를 담고, 요청 맥락 항목에는 Host와 User-Agent가 있습니다. 응답 헤더는 응답의 위치나 응답한 서버에 대한 정보를 담으며 Allow, Server가 응답 맥락 항목에 있습니다. 표현 헤더는 본문의 MIME 타입이나 적용된 인코딩·압축처럼 본문에 관한 정보를 담습니다.

같은 문서는 프록시가 헤더를 다루는 방식으로도 나눕니다. 종단 간(end-to-end) 헤더는 요청이면 서버, 응답이면 클라이언트인 최종 수신자까지 전달되고, 중간 프록시는 이를 바꾸지 않고 다시 보내며 캐시는 저장합니다. 홉 단위(hop-by-hop) 헤더는 한 번의 전송 계층 연결에서만 의미가 있어 프록시가 다시 보내거나 캐시하지 않고, Connection 헤더로 지정할 수 있는 것도 이 종류뿐입니다.

헤더는 본문을 해석하는 방법을 담고 실제 데이터는 본문에 실립니다. MDN의 Fetch API 사용 안내는 POST 요청에서 Content-Type 헤더가 요청 본문의 형식을 서버에 알린다고 설명합니다. 본문이 없는 GET 요청으로 데이터를 보낼 때는 URL 뒤에 쿼리 문자열로 붙이는 방식이 흔하다고 같은 안내는 적었습니다.

Fetch API 호출과 CORS의 헤더 조건

브라우저 JavaScript에서 외부 API를 부를 때는 MDN의 Fetch API 사용 안내에 나온 대로 fetch()의 headers 옵션에 객체를 넘기거나, Headers 객체에 Headers.append()로 헤더를 추가한 뒤 넘깁니다. 안내의 예시는 JSON 본문을 보낼 때 Content-Type을 application/json으로 지정합니다. Headers 객체는 이름을 소문자로 바꾸고 값의 앞뒤 공백을 지우며, 브라우저가 자동으로 정해 스크립트가 바꿀 수 없는 금지된 요청 헤더(Forbidden request headers)의 설정을 막습니다.

같은 안내는 Authorization과 Proxy-Authorization 헤더를 HTTP 쿠키, TLS 클라이언트 인증서와 함께 자격 증명으로 분류합니다. credentials는 쿠키처럼 브라우저가 관리하는 자격 증명의 전송 범위를 조절하며 기본값은 same-origin입니다. 다른 출처로 보내는 요청이 단순 요청(simple request)이 아니면 브라우저가 사전 요청(preflight)을 먼저 보내고, 서버가 알맞은 CORS 헤더로 응답한 경우에만 실제 요청을 보냅니다. credentials를 include로 둔 교차 출처 요청에서는 서버가 Access-Control-Allow-Credentials를 보내고 Access-Control-Allow-Origin에 * 대신 클라이언트의 출처를 명시해야 합니다.

fetch()는 본문을 다 받기 전이라도 상태와 헤더를 받은 시점에 Response 객체를 넘기고, 스크립트는 response.headers.get("content-type")처럼 응답 헤더를 읽습니다. 읽을 수 있는 헤더는 응답 유형에 따라 걸러지며, CORS 응답에서는 기본적으로 안전 목록에 오른 헤더만 읽을 수 있고, 서버는 Access-Control-Expose-Headers로 추가 공개할 헤더를 지정합니다. 서버 쪽에서는 RFC 9110이 처리하려는 크기보다 큰 요청 헤더를 받은 서버에 알맞은 4xx 상태 코드로 응답하도록 요구합니다.