1. لائبريري
  2. HTTP와 웹
  3. HTTP 헤더

요청 헤더

اپڊيٽ ٿيل -1 m

URL은 리소스를 가리킬 수 있지만, XML 대신 JSON을 달라고 요청하지는 못합니다. 로그인 상태를 증명할 수도 없습니다. 어제 방문했다는 사실을 기억하지도 못합니다. 여러 사이트가 하나의 IP 주소를 공유할 때 어느 웹사이트를 원하는지조차 알릴 수 없습니다.

요청 헤더가 이 모든 것을 해결합니다. 단순히 뭔가를 가리키는 포인터를, 클라이언트와 서버가 주고받는 정교한 대화로 바꿔놓습니다.

헤더가 요청에 목소리를 부여하는 방법

https://api.example.com/users/123을 요청할 때, URL은 무엇을 원하는지만 지정합니다. 하지만 다음에 대해서는 아무것도 말하지 않습니다:

  • JSON을 원하는지 XML을 원하는지
  • 인증이 되어 있는지
  • 어떤 언어를 선호하는지
  • 캐시된 버전이 있는지
  • 어떤 브라우저를 사용하는지

헤더가 이 공백을 채웁니다. 단순히 무언가를 가리키는 것과, 그것에 대해 실제로 소통하는 것의 차이가 바로 헤더에 있습니다.

모든 요청에 필요한 헤더

Host: 어느 문을 두드리고 있나요?

Host: www.example.com

이 헤더는 HTTP/1.1에서 필수입니다. 이유는 간단합니다. 하나의 IP 주소가 수백 개의 웹사이트를 호스팅할 수 있습니다. 요청이 그 IP에 도착하면 서버는 어느 사이트를 원하는지 알아야 합니다. Host 헤더가 그 답을 줍니다.

호스트 이름이 URL에 이미 있더라도, 원시 HTTP 메시지에 명시적으로 필요하기 때문에 헤더로 다시 전송합니다.

User-Agent: 누가 요청하나요?

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

브라우저나 애플리케이션의 정체를 알려주는 헤더입니다. 서버는 이 정보를 분석, 호환성 판단, 봇 탐지, 모바일 최적화에 활용합니다.

User-Agent 문자열은 브라우저 역사의 살아있는 박물관입니다. 현대 브라우저들은 여전히 "Mozilla"라고 자처하는데, 1996년 Netscape(Mozilla)가 더 풍부한 콘텐츠를 받았고, 그 이후의 모든 브라우저는 단순화된 페이지를 받지 않으려면 그 거짓말을 이어가야 했기 때문입니다. 우리는 아직도 그 속임수의 유산 속에 살고 있습니다.

현대 웹 개발은 대부분 User-Agent 스니핑 대신 기능 감지를 선호하지만, 이 헤더는 여전히 어디에나 살아있습니다.

Accept: 무엇을 받을 수 있나요?

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

이 헤더는 콘텐츠 협상을 가능하게 합니다—동일한 URL이 요청자의 선호에 따라 다른 형식을 반환하는 것입니다. q 값은 선호도를 나타냅니다: HTML이 최우선(암묵적으로 q=1.0), XML은 그다음(q=0.9), 그 외 모든 것은 마지막(q=0.8)입니다.

API 엔드포인트는 JavaScript 앱에게는 JSON을, 레거시 시스템에게는 XML을 반환할 수 있습니다. 같은 URL, 다른 대화입니다.

Accept-Language: 어떤 언어를 사용하나요?

Accept-Language: en-US,en;q=0.9,es;q=0.8

서버에게 이렇게 말하는 겁니다: "미국 영어를 선호하지만, 영어라면 뭐든 괜찮고, 스페인어도 됩니다." 웹사이트는 이 정보를 활용해 묻지 않고도 자동으로 사용자의 언어로 콘텐츠를 보여줍니다.

Accept-Encoding: 얼마나 압축할 수 있나요?

Accept-Encoding: gzip, deflate, br

현대 브라우저는 여러 압축 알고리즘을 지원합니다. 압축 해제 가능한 방식을 미리 알려주면, 서버가 응답을 대폭 줄일 수 있습니다. 100KB HTML 파일이 gzip으로 20KB까지 줄어들기도 합니다.

신원 증명

Authorization: 자격 증명

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

신원 증명을 담는 헤더입니다. 주요 방식은 다음과 같습니다:

  • Basic: Base64로 인코딩된 사용자 이름과 패스워드 (HTTPS에서만 안전)
  • Bearer: OAuth 2.0 또는 JWT 토큰
  • Digest: 자격 증명의 암호화 해시
  • API Key: 프로그래밍 방식 접근을 위한 독자적 방식

잘못된 자격 증명을 보내면 401 Unauthorized 응답이 돌아옵니다.

Cookie: 기억의 매개체

Cookie: sessionId=abc123; preferences=dark-mode

HTTP는 무상태 프로토콜입니다—각 요청은 이전 요청을 전혀 기억하지 못하는 독립적인 존재입니다. 쿠키가 이 한계를 극복합니다. 서버가 쿠키를 설정하면, 브라우저는 이를 저장하고 해당 도메인으로 보내는 이후 요청마다 자동으로 함께 전송합니다.

로그인 상태를 유지하고, 사용자 설정을 기억하고, 페이지 간 행동을 추적하는 것이 모두 이 방식으로 이루어집니다.

캐싱: 이미 있는 건 다시 보내지 마세요

If-Modified-Since

If-Modified-Since: Wed, 21 Oct 2024 07:28:00 GMT

"이 날짜 이후에 변경된 경우에만 새 버전을 주세요"라고 서버에 알리는 헤더입니다.

변경이 없다면 서버는 본문 없이 304 Not Modified를 반환합니다. 브라우저는 캐시에 저장된 사본을 사용합니다. 대역폭이 그만큼 절약됩니다.

If-None-Match

If-None-Match: "686897696a7c876b7e"

ETag(엔티티 태그)는 타임스탬프보다 훨씬 정밀합니다. 서버가 각 버전에 고유한 식별자를 부여합니다. 캐시에 저장된 ETag가 현재 것과 일치하면 콘텐츠가 바뀌지 않은 것입니다—304를 받고 캐시를 사용하면 됩니다.

보안: 어디서 왔나요?

Origin

Origin: https://www.example.com

CORS(Cross-Origin Resource Sharing) 보안의 핵심 헤더입니다. 한 도메인의 JavaScript가 다른 도메인에서 데이터를 요청할 때, 브라우저는 자동으로 Origin 헤더를 포함시킵니다. 서버는 이를 확인하고 접근 허용 여부를 결정합니다.

중요한 점은, JavaScript가 이 헤더를 위조할 수 없다는 것입니다. 브라우저가 크로스 오리진 요청에 자동으로 설정하기 때문에, 악성 사이트가 신뢰할 수 있는 사이트를 사칭하는 것을 막을 수 있습니다.

Referer

Referer: https://www.example.com/previous-page

철자가 틀렸다는 점에 주목하세요—원래 HTTP 명세의 오타가 그대로 표준이 되어버린 경우입니다.

현재 요청에 링크한 페이지를 서버에 알려주는 헤더입니다. 트래픽 분석(방문자가 어디서 오는가?), 보안(요청이 예상된 경로에서 시작됐는가?), 탐색 맥락 파악에 활용됩니다.

개인 정보 보호 문제로 인해 Referrer-Policy 헤더가 등장했으며, 이 정보를 얼마나 공유할지 제어할 수 있습니다.

연결 관리

Connection과 Keep-Alive

Connection: keep-alive
Keep-Alive: timeout=5, max=100

TCP 연결을 여는 것은 비용이 큽니다—채널 하나를 수립하는 데만 여러 번의 왕복이 필요합니다. HTTP/1.1은 기본적으로 연결을 유지하여 여러 요청이 동일한 연결을 통해 처리되도록 합니다.

Connection: close는 응답 후 연결을 끊어도 된다는 신호를 서버에 보냅니다.

부분 요청: 일부만 받을게요

Range

Range: bytes=0-1023

리소스의 특정 부분만 요청하는 헤더입니다. 다음 상황에서 필수적입니다:

  • 재개 가능한 다운로드: 실패한 다운로드를 중단된 지점에서 이어받기
  • 동영상 스트리밍: 작은 단위로 순차 요청
  • 대용량 파일 처리: 파일 전체 대신 헤더 부분만 읽기

서버는 206 Partial Content와 함께 요청된 바이트를 반환합니다.

프록시가 개입할 때

X-Forwarded-For

X-Forwarded-For: 203.0.113.195, 70.41.3.18

요청이 프록시나 로드 밸런서를 거치면, 서버는 사용자의 IP 대신 프록시의 IP를 보게 됩니다. 이 헤더는 경유한 IP 주소들의 체인을 보존합니다—가장 왼쪽이 원래 클라이언트의 IP입니다. 보안 로깅, 속도 제한, 지리적 위치 파악에 매우 중요합니다.

X-Forwarded-Proto

X-Forwarded-Proto: https

로드 밸런서가 외부에서 HTTPS를 처리한 뒤, 백엔드 서버에는 일반 HTTP로 요청을 전달하는 경우가 많습니다. 이 헤더는 원래 연결이 안전한 HTTPS였다는 사실을 백엔드에 알려주어, HTTPS URL을 올바르게 생성하고 보안 정책을 제대로 적용하게 합니다.

커스텀 헤더: 대화를 더 풍부하게

X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-API-Version: 2024-10-01
X-Client-Version: 1.2.3

애플리케이션은 다음과 같은 목적으로 커스텀 헤더를 추가합니다:

  • 요청 추적: 분산 시스템에서 요청의 경로를 따라가는 고유 ID
  • API 버전 관리: 특정 API 버전 지정
  • 기능 플래그: 실험적 기능 활성화
  • 클라이언트 메타데이터: 앱별 부가 정보

"X-" 접두사는 새 헤더에는 더 이상 권장되지 않지만, 레거시 시스템에는 여전히 넘쳐납니다.

요청 헤더에 대해 자주 묻는 질문

브라우저가 보내는 헤더를 직접 볼 수 있나요?

물론입니다. 브라우저의 개발자 도구(F12)를 열고, 네트워크 탭에서 아무 요청이나 클릭하면 헤더 섹션에서 모든 HTTP 트랜잭션의 요청 헤더와 응답 헤더를 확인할 수 있습니다.

JavaScript로 모든 요청 헤더를 수정할 수 있나요?

아닙니다. 브라우저는 보안을 위해 특정 헤더를 수정하지 못하도록 막습니다. JavaScript는 fetch나 XMLHttpRequest를 통해 Host, Origin, Referer, Cookie(직접), User-Agent를 수정할 수 없습니다. 이 제한 덕분에 악성 스크립트가 다른 사이트나 사용자를 사칭하는 것을 막을 수 있습니다.

일부 헤더가 X-로 시작하는 이유가 뭔가요?

역사적으로 "X-" 접두사는 실험적이거나 비표준 헤더를 의미했습니다. 지금은 이 관례가 더 이상 권장되지 않아, 새 커스텀 헤더는 접두사 없이 설명적인 이름을 사용하도록 합니다. 하지만 X-Forwarded-For, X-Request-ID처럼 기존에 자리잡은 헤더들은 여전히 이 방식을 쓰고 있습니다.

서버가 모르는 헤더를 보내면 어떻게 되나요?

아무 문제 없습니다. 서버는 이해하지 못하는 헤더를 그냥 무시합니다. 이것은 설계 의도입니다—기존 호환성을 깨지 않고 새 헤더를 점진적으로 도입할 수 있게 해줍니다. 커스텀 X-My-Special-Header를 보내도, 그 헤더를 모르는 서버는 조용히 무시할 뿐입니다.

اڳيون

CORS 헤더

پويون

인증 헤더

ڇا هي صفحو مددگار هو؟

😔
🤨
😃