[네트워크] HTTP Header: Virtual Hosting, 컨텐츠 협상, Accept의 우선순위, Authorization, Cache-Control

 

반응형

🌏 HTTP Header 주요 필드

✅ Host

• 클라이언트가 요청을 보낼 때 도메인 이름을 명시하는 헤더
• 하나의 IP 주소에서 여러 도메인을 운영하는 가상 호스팅(Virtual Hosting) 환경에서 필수적
• HTTP/1.1부터 Host 헤더가 필수가 됨 (HTTP/1.0까지는 선택이었음)
• 예시
  • Host: www.example.com

✔️ Virtual Hosting이란?

하나의 서버(즉, 하나의 IP 주소)에서 여러 웹사이트를 동시에 운영하는 환경을 가상 호스팅(Virtual Hosting)이라고 하는데, 이때 Host 헤더가 필수적입니다.

예를 들어 같은 서버에서 www.cafe.com, www.shop.com, www.blog.com 세 사이트를 운영한다면, 서버 입장에서는 단순히 IP만 보고는 요청이 어느 사이트를 위한 것인지 알 수 없습니다. 그래서 클라이언트가 요청을 보낼 때 Host: www.shop.com이라는 헤더를 함께 전달하면, 서버는 이를 보고 “아, 이건 쇼핑몰 사이트 요청이구나”라고 구분해 올바른 자원으로 라우팅할 수 있습니다. 결국 Host 헤더는 하나의 서버에서 여러 도메인을 동시에 서비스할 수 있도록 만들어주는 핵심적인 장치입니당

✅ Content-Type

• 요청이나 응답 본문이 어떤 형식(MIME Type)인지 알려주는 헤더
  • 요청에서 쓰이면 클라이언트가 서버로 보내는 데이터의 형식 지정 (주로 POST 메서드 같은 것)
  • 응답에서 쓰이면 서버가 클라이언트로 돌려줄 데이터 형식 지정
• 서버와 클라이언트가 데이터를 올바르게 해석할 수 있도록 도와줌
• 자주 쓰이는 값
  • application/json → JSON 데이터
  • application/x-www-form-urlencoded → HTML 폼 데이터 기본 형식
  • multipart/form-data → 파일 업로드 시 사용
• 예시
  • Content-Type: application/json

Content-Type은 본문이 있을 때 반드시 필요한 헤더는 아니지만, 없으면 클라이언트/서버가 데이터를 해석할 수 없습니다. 따라서 POST/PUT/PATCH 요청에서 본문을 보낼 때는 사실상 필수적입니다.

✅ Accept

• 클라이언트가 서버에게 “나는 이런 형식의 응답을 원해요”라고 알리는 헤더 (요청 헤더로만 보통 쓰임)
• 서버는 이 값을 참고해서 응답 콘텐츠 타입을 결정
• 예시
  • Accept: application/json
  • Accept: text/html

✔️ 컨텐츠 협상 (Content Negotiation)

웹에서 클라이언트와 서버가 데이터를 주고받을 때는 단순히 요청과 응답만 있는 게 아니라, 서로 어떤 형식으로 데이터를 주고받을지 협상하는 과정이 있습니다. = Content Negotiation

클라이언트는 서버에 요청을 보낼 때 Accept 헤더를 통해 “나는 이런 형식의 데이터를 선호한다”라고 알려줍니다. 예를 들어 Accept: application/json이라고 보내면, 클라이언트는 JSON 데이터를 원한다는 뜻이 됩니다. 만약 브라우저라면 Accept: text/html을 보내 HTML 페이지를 요청하기도 하고, API 클라이언트라면 JSON을 선호한다고 알려줄 수 있습니다.

서버는 이 정보를 보고, 자신이 제공할 수 있는 응답 형식 중 클라이언트가 원하는 것을 선택해 돌려줍니다. 즉, 같은 엔드포인트를 호출해도 클라이언트가 Accept를 어떻게 설정했는지에 따라 응답이 달라질 수 있습니다.

결국 콘텐츠 협상은 클라이언트와 서버가 서로 원하는 데이터 형식을 맞춰가는 대화 방식입니다.

✔️ Accept 우선순위 값 (q)

클라이언트는 q라는 우선순위 값을 붙여 “나는 JSON을 제일 원하지만, HTML도 괜찮음”이라고 표현할 수도 있습니다. 예를 들어 Accept: application/json; q=0.9, text/html; q=0.8이라면 서버는 JSON을 우선적으로 주되, JSON이 안 되면 HTML로 응답해도 괜찮다는 의미입니다.

✅ Authorization

• 클라이언트가 서버에 자신을 증명할 때 사용하는 인증 정보 헤더
• 형식
  • Authorization: <타입> <자격 증명>
• 이때 타입에 따라 인증 방식이 달라집니다.

1. Basic
   • 가장 단순한 방식. 아이디와 비밀번호를 아이디:비밀번호 형태로 합쳐 Base64로 인코딩해 전송합니다.
   • 대놓고 비밀번호가 떠다니기 때문에 보안상 안전하지 않아 반드시 HTTPS와 함께 써야 합니다.
2. Bearer
   • 토큰 기반 인증 방식. 서버가 발급한 토큰(JWT, OAuth 액세스 토큰 등)을 담아 요청을 보냅니다.
   • 서버는 이 토큰을 검증해 클라이언트가 유효한 사용자인지 판단합니다.
3. API Key
   • 서비스에서 발급한 키를 Authorization 헤더나 쿼리스트링으로 전달합니다.
   • API Key는 Authorization 헤더가 아니라 x-api-key 같은 커스텀 헤더에 담는 경우도 많습니다.

✅ Cache-Control

• 요청이나 응답에 대해 캐싱 정책을 지정하는 헤더
• 브라우저, 프록시, CDN이 캐시를 어떻게 처리해야 하는지 알려줌
• 주요 디렉티브
  • no-cache
    • 캐싱 가능하지만 사용 전 반드시 서버 검증 필요
    • 다시 사용할 때는 서버에 ETag나 Last-Modified 등을 확인한 후 사용합니다.
  • no-store
    • 아예 캐싱 금지입니다. 로컬 디스크나 메모리에 저장조차 하면 안 됩니다.
    • 금융 정보, 개인정보처럼 민감한 데이터를 다룰 때 사용됩니다.
  • max-age=60
    • 60초 동안 캐시 유효
• 예시
  • Cache-Control: no-store
  • Cache-Control: max-age=3600

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!