HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📲
웹 구조/
HTTP 헤더 - 일반 헤더

HTTP 헤더 - 일반 헤더

생성일
Sep 14, 2021 07:40 AM
태그
표현
협상
전송 방식
쿠키
정보
인증

HTTP 헤더 개요

헤더 필드는 field-name: field-value 형태이며, field-name은 대소문자 구분하지 않는다.
HTTP 헤더에는 HTTP 전송에 필요한 모든 부가정보를 담는다. ex) 메세지 바디의 크기, 압축, 인증, 서버 정보 ...
표준 헤더가 엄청 많고, 필요 시에는 임의의 헤더도 추가 가능하다.
 

헤더 분류

  • General 헤더: 메세지 전체에 적용되는 정보 ex) Connection: close
  • Request 헤더: 요청 정보 ex) User-Agent: Mozilla/5.0
  • Response 헤더: 응답 정보 ex) Server: Apache
  • Entity 헤더 → 표현 헤더: 엔티티 바디 → 표현 데이터 정보 ex) Content-Type: text/html
 
RFC2616 → RFC7230 ~ 7235로 바뀌면서 Entity 라는 용어가 사라지고 표현이라는 용어가 생김
표현(Representation) = 표현 메타데이터 + 표현 데이터로, 요청이나 응답에서 전달할 실제 데이터이다.
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
 

표현

표현 헤더는 요청, 응답 시에 모두 사용 가능하다.
  • Content-Type: 표현 데이터의 형식을 설명 (미디어 타입, 문자 인코딩) ex) application/json, image/png ...
  • Content-Encoding: 표현 데이터의 압축 방식을 나타냄 → 데이터를 읽는 쪽에서 인코딩 헤더 정보를 보고 해당 방식으로 압축 해제함 ex) gzip, deflate, identity(동일하다는 뜻으로 압축하지 않음을 의미)
  • Content-Language: 표현 데이터의 자연 언어를 표현 ex) ko, en, en-US ...
  • Content-Length: 표현 데이터의 길이를 바이트 단위로 나타냄, 그런데 전송 방식이 분할 전송(Transfer-Encoding)일 경우에는 Content-Length 사용하면 안됨
 

콘텐츠 협상

협상 헤더는 요청시에만 사용 가능하다. 협상 헤더에는 클라이언트가 선호하는 표현을 서버에 요청하는 내용이 담긴다.
  • Accept: 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset: 클라이언트가 선호하는 문자 인코딩 전달
  • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 전달
  • Accept-Language: 클라이언트가 선호하는 자연 언어 전달
 
하나의 예시를 살펴보자.
클라이언트는 한국어 브라우저를 사용하고 있는 상황에 어떤 이벤트 페이지에 들어가려는 요청을 보냈다. 해당 요청을 받은 서버는 다중 언어를 지원하는 서버인데, 클라이언트가 어떤 언어를 선호하는지 알려주지 않아 기본 언어인 영어로 응답했다. 이럴 때, Accept-Language에 한국어를 선호한다고 전달해주면 서버는 그 요청을 보고 해당 언어로 응답할 것이다.
그런데, 만약 서버가 지원하는 언어 중에 클라이언트가 선호하는 언어가 없다면? 이 때도, 기본 언어로 응답할 것이다.
그래서 클라이언트는 한가지 언어만 작성하기 보다는 여러 언어를 작성하되, 우선 순위를 정해서 전달해주면 자신이 선호하는 콘텐츠를 얻게 될 것이다.
우선순위는 0~1 사이의 Quality Values(q) 값을 사용하며, 숫자가 클수록 높은 우선순위를 갖는다. 아무것도 적혀있지 않으면 q=1이 생락되어 있는 것이다.
notion image
그리고 Accept에도 여러가지 미디어 타입을 전달할 수 있는데, 더 구체적인 것이 우선순위가 높다.
notion image
이 때는 text/plain;format=flowed → text/plain → text/* → */* 순이 되는 것이다.
 

전송 방식

  • 단순 전송
    • 단순히 Content-Length만큼의 데이터를 전송하는 방식
  • 압축 전송
    • 데이터를 압축해서 전송하는 방식으로, Content-Encoding 방식을 나타내줘야함
  • 분할 전송
    • Transfer-Encoding: chunked → 데이터를 분할하여 전송함
        • 5바이트 Hello → 5바이트 World → 0 엔터 (끝)
        5바이트 Hello → 5바이트 World → 0 엔터 (끝)
    • 분할해서 전송하기 때문에 Content-Length를 작성하지 않음
  • 범위 전송
    • 데이터를 전송하던 중에 오류로 인해 전송이 중단되었을 때, 다시 요청을 해야하는 상황에서 이미 받은 데이터를 제외하고 받지 못한 데이터만 받고 싶을 때 범위를 지정하여 요청하면, 해당 범위의 데이터만 전송함 (Content-Range: bytes 1001-2000 / 2000)
 

일반 정보

  • from: 유저 에이전트의 이메일 정보를 담음
    • 요청에서 사용
    • 일반적으로 잘 사용되지 않지만, 검색 엔진 같은 곳에서 사용됨
  • referer: 현재 요청된 페이지의 이전 웹 페이지 주소를 담음
    • 요청에서 사용
    • 이를 통해 유입 경로를 분석할 수 있음
  • user-agent: 클라이언트의 애플리케이션 정보 (웹 브라우저 정보 등)를 담음
    • 요청에서 사용
    • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
  • server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 담음
    • 응답에서 사용
    • ORIGIN 서버: 요청이 서버로 전달될 때 까지 여러 프록시 서버를 거쳐가는데, 그 중 맨 마지막 서버 = 클라이언트가 요청한 데이터를 제공하는 서버
  • date: 메세지가 발생한 날짜와 시간을 담음
    • 응답에서 사용
      •  

특별한 정보

  • Host: 요청한 호스트 정보(도메인)를 담음
    • 요청에서 사용
    • 하나의 서버가 여러 도메인을 처리해야 할 때나 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 Host 정보를 전달해주지 않으면 문제가 발생하기 때문에 필수로 작성해야함
  • Location: 리다이렉션될 페이지 URL를 담음
    • 응답에서 사용
    • 201 코드에서 사용되는 Location 값은 요청에 의해 생성된 리소스 URL
    • 3xx 코드에서 사용되는 Location 값은 요청을 자동으로 리다이렉션 하기 위한 대상 리소스 URL
  • Allow: 허용 가능한 HTTP 메서드를 알려줌
    • 405 Method Not Allowed 응답에서 사용
  • Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간을 나타냄
    • 503 Service Unavailable 응답에서 사용
    • 서비스가 언제까지 불능인지 알려주며 이 시간을 날짜로 표기할 수도, 초단위로 표기할 수도 있음
 

인증

  • Authorization: 클라이언트 인증 정보를 인증 메커니즘에 맞게 전달함
    • 요청에서 사용
  • WWW-Authenticate: 리소스 접근 시 필요한 인증 방법을 정의해 전달함
    • 401 Unauthorized 응답에서 사용
      •  

쿠키

쿠키를 사용하지 않을 때의 상황을 보자.
클라이언트가 /welcome 페이지에 접근해서 서버는 '안녕하세요. 손님' 이라는 텍스트를 전달해주었다. '홍길동' 유저가 로그인을 하고 나서, /welcome 페이지에 접근했을 때 '안녕하세요. 홍길동님' 이라고 나타나길 원하는데, '안녕하세요. 손님' 이라고 나타나게 된다.. 왜냐하면 HTTP는 무상태 프로토콜을 하기 때문에, 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어져서 서버는 이전 요청을 기억하지 못한다.
그러면 모든 요청 URL에 사용자 정보를 포함해서 전달해주면 되지 않는가? 가능은 하지만, 모든 요청에 사용자 정보가 포함되도록 일일이 개발해야하고, 브라우저를 완전히 종료하고 다시여는 상황에는 또 문제가 발생한다.
이와 같은 이유로, 우리는 쿠키를 사용한다.
로그인을 할 때, 클라이언트가 정보를 넘겨주면 서버에서 Set-Cookie 헤더로 쿠키를 만든다. 이 쿠키는 쿠키 저장소에 보관해두고, 클라이언트는 Cookie 헤더를 통해 서버에 요청한다.
 
쿠키는 보통 사용자 로그인 세션 관리, 광고 정보 트래킹 등에 사용되며, 쿠키 정보는 항상 서버에 전송된다. 이 때, 네트워크 트래픽이 추가 유발될 수 있기 때문에 최소한의 정보만 사용하는 것이 좋다. 또는 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하는 웹 스토리지(localStorage, sessionStorage)도 있다. 그리고 주민번호, 신용카드 번호 등 보안에 민감한 데이터는 쿠키에 저장하면 안된다.
 

쿠키 - 생명주기

  • expires
    • GMT 기준으로 날짜, 시간을 입력함
    • 만료일이 되면 쿠키를 삭제함
  • max-age
    • 초단위로 작성하며, 0이나 음수를 지정할 경우에는 쿠키가 삭제됨

쿠키 - 도메인

  • domain
    • 도메인을 지정하는 경우에는 명시한 도메인과 서브 도메인에서 쿠키를 접근할 수 있음
    • 도메인 지정을 생략하는 경우에는 현재 문서 기준 도메인만 쿠키에 접근할 수 있음

쿠키 - 경로

  • path
    • 해당 경로를 포함한 하위 경로 페이지만 쿠키 접근 가능
    • 일반적으로 path=/ (루트)로 지정

쿠키 - 보안

  • Secure
    • 원래 쿠키는 http, https를 구분하지 않고 전송하는데, 이를 적용하면 https인 경우에만 전송함
  • HttpOnly
    • XSS 공격 방지
    • 자바스크립트에서 접근 불가하고, HTTP 전송에만 사용함
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송함