[HTTP] 7. HTTP 헤더 - 일반 헤더

1. HTTP 헤더 개요

1. HTTP 전송에 필요한 모든 부가정보
2. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등
3. 표준 헤더가 너무 많음
4. 필요시 임의의 헤더 추가 가능

과거 표준 (RFC 2616)

HTTP 헤더
General 헤더: 메시지 전체에 적용되는 정보, ex) Connection: close
Request 헤더: 요청 정보, ex) User-Agent: Mozilla/5.0
Response 헤더: 응답 정보, ex) Server: Apache
Entity 헤더: 엔티티 바디 정보, ex) Content-Type: text/html, Content-Length: 3423


HTTP 바디
메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용
엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공

1999년 RFC2616 (폐기)
2014년 RFC7230~7235 (등장)

현재 표준 (RFC 7230)

HTTP 헤더
엔티티(Entity) -> 표현(Representation)으로 개념이 바뀌었다.
Representation = representation Metadata + Representation Data


HTTP 바디
메시지 본문(message body)을 통해 표현 데이터 전달
메시지 본문 = 페이로드(payload) - 보내고자하는 데이터 그 자체
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야하지만, 여기서 생략

페이로드(payload)는 택배를 예시로 들자면,
택배를 보낼 물건 - payload임
택배와 관련된 송장 정보들 - payload가 아님

2. 표현 (representation)

헤더	의미	상세 설명	예시
Content-Type	표현 데이터의 형식	전송되는 데이터의 미디어 타입과 문자 인코딩 방식을 지정	text/html; charset=utf-8 application/json image/png
Content-Encoding	표현 데이터의 압축 방식	데이터를 전송 전 압축할 때 사용한 인코딩 방식을 지정. 수신 측은 이 정보를 사용해 압축을 해제함	gzip deflate identity (압축 없음)
Content-Language	표현 데이터의 자연 언어	콘텐츠가 작성된 언어 또는 지역 코드를 지정	ko en en-US
Content-Length	표현 데이터의 길이	본문의 크기(바이트 단위)를 지정. 단, Transfer-Encoding 사용 시에는 포함하지 않음	348

표현 헤더는 전송, 응답 둘다 사용

3. 협상 (content negotiation)

클라이언트가 선호하는 표현 요청
1. Accept: 클라이언트가 선호하는 미디어 타입 전달
2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩
3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
4. Accept-Language: 클라이언트가 선호하는 자연 언어
협상 헤더는 요청시에만 사용
협상의 우선 순위를 정하기 위해서 Quality Values(q) 값 사용한다.

협상과 우선순위1

0~1 사이의 값을 가지고, 클수록 높은 우선순위를 가진다.
생략하면 1이다.

예시
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
1. ko-KR;q=1 (생략)
2. ko;q=0.9
3. en-US;q=0.8
4. 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

구체적인 것을 기준으로 미디어 타입을 맞춘다.

예시
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

MIME 타입	품질 지수(q값)
text/html;level=1	1.0
text/html	0.7
text/plain	0.3
image/jpeg	0.5
text/html;level=2	0.4
text/html;level=3	0.7

4. 전송방식

전송 방식	관련 헤더	설명	비고
단순 전송	Content-Length	콘텐츠의 전체 길이를 미리 알고 있을 때 사용. 한 번에 전송하고 한 번에 수신함	정적 파일 등 고정 길이 데이터
압축 전송	Content-Encoding	데이터를 전송 전에 압축함. 클라이언트는 Content-Encoding 정보를 이용해 압축 해제	gzip, deflate, br 등
분할 전송	Transfer-Encoding: chunked	데이터의 전체 크기를 알 수 없을 때 조각(chunk) 단위로 전송	Content-Length 사용 금지
범위 전송	Range, Content-Range	요청 시 또는 응답 시 일부 데이터만 선택적으로 전송	대용량 파일 다운로드, 이어받기 기능 등

5. 일반 정보

헤더	의미	상세 설명	사용 위치	예시
From	유저 에이전트의 이메일 정보	요청을 보낸 사용자나 에이전트의 이메일 주소를 표시. 일반적으로 잘 사용되지 않으며 검색 엔진 등에서 활용	요청(Request)	From: user@example.com
Referer	이전 웹 페이지 주소	현재 페이지로 이동하기 전 방문한 페이지의 URL. 유입 경로 분석에 활용 가능. (원래 표기는 Referrer지만 오타가 표준이 됨)	요청(Request)	Referer: https://example.com/pageA
User-Agent	유저 에이전트 애플리케이션 정보	요청을 보낸 클라이언트의 브라우저, OS, 디바이스 정보를 포함. 통계나 장애 분석에 활용	요청(Request)	User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Server	오리진 서버의 소프트웨어 정보	응답을 생성한 서버의 소프트웨어 종류 및 버전을 명시	응답(Response)	Server: Apache/2.2.22 (Debian) Server: nginx
Date	메시지 생성 일시	HTTP 메시지가 생성된 날짜와 시간(GMT 기준)을 명시	응답(Response)	Date: Tue, 15 Nov 1994 08:12:31 GMT

6. 특별한 정보

헤더	의미	상세 설명	사용 위치	예시
Host	요청한 호스트 정보(도메인)	요청이 전송되는 호스트명과 포트번호를 지정. 하나의 서버가 여러 도메인을 처리할 때 필수	요청(Request)	Host: www.example.com
Location	페이지 리다이렉션	브라우저가 이동해야 할 리소스의 새 위치를 지정. • 201 Created → 생성된 리소스의 URI • 3xx 응답 → 리다이렉션 대상 URI	응답(Response)	Location: https://example.com/new-page
Allow	허용 가능한 HTTP 메서드	요청된 리소스에 대해 허용된 HTTP 메서드 목록을 명시. 405 Method Not Allowed 응답 시 필수	응답(Response)	Allow: GET, HEAD, PUT
Retry-After	재요청 대기 시간	클라이언트가 다음 요청 전 대기해야 하는 시간을 명시. 주로 503 Service Unavailable 응답 시 사용	응답(Response)	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120
Authorization	인증 정보 전달	클라이언트가 서버에 인증 정보를 전달	요청(Request)	Authorization: Basic xxxxxxxxxx
WWW-Authenticate	인증 방식 정의	보호된 리소스에 접근할 때 필요한 인증 방법을 서버가 명시	응답(Response)	WWW-Authenticate: Basic realm="Access to the site"

TCP/IP는 IP로만 통신을 하기 때문에, 도메인 정보가 담긴 Host가 필수적으로 있어야한다.

7. 쿠키

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

쿠키가 필요한 이유 (로그인 예시)
Stateless한 HTTP 특성상 로그인한 상태 서버는 모른다.
대안: 모든 요청에 사용자 정보 포함
-> 모든 요청에 사용자 정보가 포함되도록 개발 해야함
-> 브라우저를 완전히 종료하고 다시 열면?
문제가 많다...

쿠키 흐름

1. 서버에서 Set-Cookie를 통해 로그인 정보를 쿠키로 말고, 클라이언트에서 쿠키 저장소에 저장한다.

2. 클라이언트는 이후 쿠키 저장소에서 조회해서 Cookie 정보에 로그인 정보를 넣어서 요청을 보낸다.

사용처
1. 사용자 로그인 세션 관리
2. 광고 정보 트래킹


쿠키 정보는 항상 서버에 전송됨
1. 네트워크 트래픽 추가 유발
2. 최소한의 정보만 사용(세션 id, 인증 토큰)
3. 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage)


주의!
보안에 민감한 데이터는 저장하면 안됨 (주민번호, 신용카드 번호 등등)

쿠키 - 생명주기

1. Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
   만료일이 되면 쿠키 삭제
2. Set-Cookie: max-age=3600 (3600초)
   0이나 음수를 지정하면 쿠키 삭제
3. 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지
4. 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

1. 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
   domain=example.org를 지정해서 쿠키 생성
   example.org는 물론이고
   dev.example.org도 쿠키 접근
2. 생략: 현재 문서 기준 도메인만 적용
   example.org에서 쿠키를 생성하고 domain 지정을 생략
   example.org에서만 쿠키 접근
   dev.example.org는 쿠키 미접근

도메인을 명시하는 것과 안하는 것으로 쿠키 활용 범위가 달라진다.

쿠키 - 경로

Path
이 경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/루트 로 지정

쿠키 - 보안

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

8. 정리하며...

현재 기억에 남는 것은 쿠키의 흐름과 활용방식에 대해서만 기억이 난다.
용어가 많아 한눈에 안 들어오는데, 중요해보이는 쿠키는 확실하게 남기고 가자...

---

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗
https://inf.run/YZxop