HTTP 헤더 - 기본헤더

이번 글에서는 HTTP 기본헤더에 대해 이야기하고자 한다.

 

헤더에 대한 이해를 높이기 위해 HTTP Message에 대한 이야기를 하고 넘어가겠다.

 

HTTP로 데이터를 주고 받을 때, HTTP Message를 이용한다.

HTTP Message를 간략하게 보자면 아래와 같이 구성되어 있다.

 

• 메세지 본문(Message Body)을 통해 표현 데이터 전달
• 메시지 본문 = 페이로드(Payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
  • 예) 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

 

표현 헤더

표현 헤더는 아래와 같이 구성되어 있다.

• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이
• HTTP 요청과 응답에서 둘 다 사용 

다음은 표현 헤더들에 대한 상세설명이다

 

1. Content-Type

• 표현 데이터의 형식 설명
• 미디어 타입, 문자 인코딩이 명시된다
• 예)
  • text/html; charset=utf-8
  • application/json (json의 경우, utf-8이 기본이다)
  • image/png

 

2. Content-Encoding

• 표현 데이터를 압축하기 위해 사용
• 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
• 데이터를 읽는 쪽에서 인코딩 헤더의 정보롤 압축 해제
• 예)
  • gzip
  • deflate
  • identity(압축 X)

 

3. Content-Language

• 표현 데이터의 자연언어를 표현
• 예)
  • ko(한국어)
  • en(영어)
  • en-US

4. Content-Length

• 표현 데이터의 길이
• 바이트 단위로 표기

 

협상(콘텐츠 네고시에이션)

 - 클라이언트가 선호하는 표현 요청

 - 클라이언트 요청 시에만 사용

 - 서버에서 협상 요청을 받으면 최대한 클라이언트의 요구에 맞춰줌

 

협상 관련 헤더 종류는 다음과 같다

• Accept: 클라이언트가 선호하는 미디어타입 전달 예) JSON, XML
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩 예) UTF-8
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 예) gzip
• Accept-Language: 클라이언트가 선호하는 자연언어 예) ko, en

 

협상 헤더를 사용하는 이유는 다음과 같다

 

Accept-Language를 예를 들자면,

 

협상 헤더를 사용하지 않으면, 클라이언트가 선호하는 자연언어를 알 수 없어

서버쪽에서 설정된 자연언어로 표현 데이터를 보내게 된다

 

협상 헤더를 사용하면, 클라이언트가 선호하는 자연언어를 알 수 있어

클라이언트쪽에서 선호하는 자연언어로 표현 데이터를 보낼 수 있게 된다

 

만약, 클라이언트 측에서 협상헤더를 사용하여 요청을 보냈는데

서버에서 지원하지 않을 때는 어떻게 할까?

 

바로, 협상 헤더에 우선순위를 두는 방법으로 해결할 수 있다.

우선순위를 두면 서버가 지원하는 헤더 중에서 높은 우선순위에 해당하는 헤더를 적용한다.

 

협상 헤더에 우선순위를 두는 방법은 아래 3가지가 존재한다

 

1. Quality Values(q)값 사용

• 0~1 범위의 값 사용
• 클 수록 높은 우선순위
• 생략하면 1
• 예) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
  • ko-KR; q=1(q값 생략되어 기본값 적용)
  • ko; q=0.9
  • en-US; q=0.8
  • en; q=0.7 

 

2. 헤더의 구체적 명시

• 구체적인 것이 우선한다.
• 예) Accept: text/*, text/plain, text/plain;format=flowed, */*
  • 우선순위
    1. text/plain;format=flowed
    2. text/plain
    3. text/*
    4. */*

 

3. Quality Values(q)값 사용과 헤더의 구체적 명시 모두 사용

• 구체적인 것을 기준으로 미디어 타입을 맞춘다.
• 예)Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 
text/html;level=2;q=0.4, */*;q=0.5

 

다음은 HTTP 전송방식과 관련 헤더에 대한 설명이다

 

HTTP 전송방식은 다음과 같이 존재한다.

• 단순전송
• 압축전송
• 분할전송
• 범위전송

 

다음은 HTTP 전송방식에 대한 상세설명이다

 

1. 단순전송

• Content의 길이만큼 전송
• Content의 전체 길이를 알 수 있을 때 사용
• Content-Length 헤더를 이용한다.

 

2. 압축전송

• 데이터를 압축하여 전송
• Content-Encoding: gzip 헤더 사용

 

3. 분할전송

• 데이터를 쪼개서 보냄
• Transfer-Encoding 헤더 사용
• 데이터의 내용을 부분적이라도 바로바로 사용하고자 할 때 사용
• 주의 - Context-Length를 사용하면 안 됨
  • 데이터를 쪼개서 전송하므로, 애초에 전체 길이 산정 불가
  • Chunk 마다 다른 길이가 존재하기 때문

 

4. 범위전송

• 특정 범위를 지정하여 데이터 전송
• 이전에 이미 받은 데이터가 있을 때 그 이후의 데이터를 요청하고자 할 때 사용
• Range(요청 시), Content-Range(응답 시) 헤더 사용

 

일반 정보 헤더

 - HTTP Message 송/수신시 필요한 일반적인 정보를 담고 있는 헤더이다

• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소
• User-Agent: 유저 에이전트 애플리케이션 정보
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
• Date: 메시지가 생성된 날짜

 

상세 설명은 다음과 같다

 

1. From

• 클라이언트의 이메일 정보
• 잘 사용되지 않음
• 검색엔진 같은 곳에서 주로 사용
• 요청에서 사용

2. Referer

• 현재 요청된 페이지의 이전 웹 페이지 주소
• 사이트 A -> 사이트 B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
• referer를 이용하여 유입경로 분석 가능
• 요청에서 사용
• 참고: referer는 단어 referrer의 오타

 

3. User-Agent

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보 등등)
• 예) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
• User-Agent 헤더 정보를 이용하여 통계 데이터 수집 가능
• 장애 시, 어떤 환경(운영체제, 브라우저 등)에서 장애가 발생하는지 파악 가능
• 요청에서 사용

4. Server

• 요청을 처리하는 Origin 서버의 소프트웨어 정보
• Origin 서버: 마지막으로 내 요청을 처리한 서버
• 예) Server: Apache/2.2.22 (Debian)
• 예) Server: nginx

5. Date

• 메세지가 발생한 날짜와 시간
• 예) Date: Tue, 15 Nov 1994 08:12:31 GMT
• 응답에서 사용

 

특별 정보 헤더

• Host: 요청한 호스트 정보(도메인)
• Location: 페이지 리다이렉션
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

상세 설명은 다음과 같다

 

1. Host

• 요청한 호스트 정보(도메인)

• 요청을 처리할 서버 지정
• HTTP Message에 필수적으로 포함되어야 함
• 아래와 같은 경우 사용
  • 하나의 서버가 여러 도메인을 처리해야 할 때
  • 하나의 IP 주소에 여러 도메인이 적용되어 있을 때
• 예) 하나의 서버에 가상 호스트가 여러 개 있는 경우

 

2. Location

• 주로 페이지 Redirection 시 사용
• 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(Redirect)
• 응답코드에 따른 Location 용도 차이
  • 201 Created: 클라이언트의 요청에 의해 생성된 리소스 URI
  • 3xx Redirection: 클라이언트의 요청을 자동으로 Redirection하기 위한 대상 리소스를 가리킴

 

3. Allow

• 허용 가능한 HTTP 메서드 종류 정보
• 405(Method Not Allowed)에서 응답에 포함해야함
• 예) Allow: GET, HEAD, PUT
• 많이 사용하지 않음

 

4. Retry-After

• 클라이언트가 다음 요청을 하기까지 기다려야 하는 시간
• 서비스 장애 시 언제 시스템이 복구되는지 알려줄 수 있음
• 503(Service Unavailable) 응답 시 포함시킬 수 있음
• 날짜 or 초 단위로 복구완료 시점이 언제인지 알려줄 수 있음
• 예)
  • Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
  • Retry-After: 120 (초단위 표기)

 

인증 헤더

인증과 관련된 헤더는 다음과 같이 존재한다.

• Authorization: 클라이언트 인증 정보를 서버에 전달(요청 시)
• WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의(응답 시)

아래는 각 인증헤더에 대한 상세설명이다.

 

1. Authorization

• 클라이언트 인증 정보를 서버에 전달
• 클라이언트가 요청을 보낼 때 사용
• 예) Authorization: Basic xxxxxxxxxxxxxxxx

 

2. WWW-Authenticate

• 리소스 접근시 필요한 인증 방법 정의
• 401 Unathorized 응답과 함께 사용
• 예)
  • WWW-Authenticate: Newauth realm="apps", type=1,
    title="Login to \"apps\"", Basic realm="simple"

 

쿠키

• 서버로부터 받은 데이터를 클라이언트의 브라우저에 저장할 때 사용
• 브라우저를 종료해도 데이터 유지

 

기본적으로 HTTP 프로토콜은 무상태(Stateless) 프로토콜이다

무상태(Stateless)란, 서버가 클라이언트의 이전 요청내용을 기억하지 않는 것을 말한다

 

예를 들어, 자동 로그인을 구현한다고 가정하자

 

쿠키를 사용하지 않는다면, 모든 요청에 사용자 계정정보를 포함시켜 보내야 한다.

서버가 기존 요청정보를 기억하고 있지 않기 때문이다.

이럴 경우, 보안 및 개발 편의성이 저하된다.

쿠키를 사용한다면, 처음 한번만 사용자 계정정보를 보내고 난 후

쿠키 만료 시까지 클라이언트가 계정정보를 일일이 신경써서 보낼 필요가 없다

쿠키에 있는 데이터를 자동으로 요청에 포함시켜 주기 때문이다

 

쿠키 저장과 관련된 헤더는 다음과 같이 존재한다.

• Set-Cookie
  • 서버에서 클라이언트로 쿠키전달
  • 응답 시 사용
  • 쿠키로 저장할 데이터의 Key-Value 값이 존재
• Cookie
  • 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달
  • 요청 시 사용
  • 서버에 전송할 쿠키의 Key-Value 값이 존재

 

쿠키 동작원리는 아래와 같다 예) 로그인

• 첫 로그인 시
  • 클라이언트가 서버에 계정정보를 전송한다
  • 서버로부터 계정정보가 저장된 쿠키를 받는다
  • 받은 쿠키를 쿠키 저장소에 저장한다

 

• 재 로그인 시
  • 쿠키 저장소에서 계정정보를 조회한다
  • 조회한 계정정보를 요청 메세지에 포함시켜 전송한다
  • 서버에서 로그인에 성공했다는 메세지를 수신한다

 

또한, 클라이언트에서 쿠키를 갖고 있을 경우,

아래와 같이 모든 요청에 대해 쿠키 데이터가 자동으로 포함되게 되어있다

 

아래는 그 밖의 쿠키와 관련된 헤더들이다.

 

1. 생명주기

• 쿠키의 만료일을 정할 수 있음
• expires(날짜) 또는 max-age(시간)로 설정가능
  • expires(날짜)
    • 지정한 날짜로 만료일 설정
    • 만료일이 되면 쿠키 삭제
    • 예) Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
  • max-age(시간)
    • 지정한 시간 동안 쿠키 유지
    • 0이나 음수를 지정하면 쿠키 삭제
    • 예) Set-Cookie: max-age=3600 (3600초)
• 만료 날짜 생략/포함에 따른 종류
  • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료 시까지만 유지
  • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

 

2. 도메인

• 쿠키를 사용할 도메인을 명시
• 쿠키를 사용할 도메인을 명시하거나 생략할 수 있음
• 예를 들어, domain=example.org라는 도메인에서 쿠키를 생성한다고 가정
  • 도메인 명시
    • 명시한 문서 기준 도메인 + 서브도메인 포함하여 쿠키 접근가능
    • domain=example.org를 지정하여 쿠키 생성
      • example.org 접근가능(기준 도메인)
      • dev.example.org 접근가능(서브 도메인)
  • 도메인 생략
    • 명시한 문서 기준 도메인 쿠키 접근가능
    • example.org에서 쿠키 생성 도메인 지정 생략
      • example.org 접근가능(기준 도메인)
      • dev.example.org 접근불가(서브 도메인)

 

3. 경로(Path)

• 쿠키 접근 가능한 특정 경로 지정
• 특정 경로를 포함한 하위 경로 페이지만 쿠키 접근가능
• 일반적으로 path=/ 루트로 지정
• 예) path=/home
  • /home/level1 -> 접근가능
  • /hello -> 접근불가
  • /home/level1/level2 -> 접근가능
  • /home -> 접근가능

4. 보안

• 쿠키와 관련된 보안 설정

1) Secure

• 일반적으로, 쿠키는 http, https를 구분하지 않고 전송
• Secure를 적용하면 https인 경우에만 전송

 

2) HTTP Only

• XSS 공격 방지
• 자바스크립트에서 접근 불가(document.cookie)
• HTTP 전송에만 사용

 

3) SameSite

• CSRF 공격 방지
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

 

아래는 쿠키 헤더 사용 예이다

• 예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

 

※ 쿠키 사용 시 주의사항

• 쿠키 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용할 것(세션 ID, 인증토큰)
• 보안에 민감한 데이터는 저장하지 말 것(예. 주민번호, 신용카드번호 등)