이 글은 김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의에 출처를 두고 있습니다.

Chap 7. 일반 헤더

1. HTTP 헤더

용도

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

최신화

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

표현

표현의 종류

• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이
• 표현 헤더는 전송, 응답 둘다 사용

1. Content-Type

'표현 데이터의 형식' 설명

미디어 타입, 문자 인코딩
ex)
• text/html; charset=utf-8
• application/json
• image/png

2. Content-Encoding

'표현 데이터' 인코딩

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

3. Content-Language

'표현 데이터' 의 자연 언어

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

4. Content-Length

'표현 데이터' 의 자연 언어

• 바이트 단위
• Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

---

협상과 우선순위

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

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어
📢 '협상 헤더'는 보통 요청시에만 사용

만약 이렇게 내가 원하는 언어가 없는 경우 협상을 어떻게 해?

if 클라이언트가 인식할 수 있는 한국어를 서버에서는 제공하지 않으면?

[방법1]

• Quality Values(q) 값 사용
• 0~1, 클수록 높은 우선순위
• 생략하면 1

그러니 당연히 생략 되있는
1순위 ko-KR;q=1 (q생략)
2순위 ko;q=0.9
3순위 en-US;q=0.8
4순위 en:q=0.7
으로 인식하기 때문에 결과는 한국어를 제공하지 않으므로 그 다음 우선순위인 '영어'로 제공

[방법2]

Quality Values(q)

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

[방법3]

Quality Values(q)

요청이 수신되어 처리중이다. [거의 사용 x]

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

text/html;level=2;q=0.4, /;q=0.5

Q. 사실 이게 무슨 말인지 이해가 안간다...

---

✨ 전송 방식 4가지

• 단순 전송 -> 단순히 한 번에 요청 & 한 번에 받음
• 압축 전송 -> 압축하여 받음
• 분할 전송
• 범위 전송

분할 전송

바이트를 먼저 보내고 이후에 값을 전송한다.

• 여기서 chunked 는 덩어리로 쪼개 보낸단 뜻
• 그리고 Content-Length는 넣어선 안된다.
  -> 애초에 길이가 얼마나 분할될지 예측이 안되니까...

분할 전송

• 어느정도의 범위를 받을지 '클라이언트'가 요청
  Content-Range: 를 통해 응답할 수 있다.

---

일반 정보

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

이 중에서 몇 개만 뽑아 설명해보자면...

From _ 잘 사용 x

유저 에이전트의 이메일 정보

• 검색 엔진 같은 곳에서 주로 사용
• 요청에서 사용

🎉 Referer

한 마디로 '이전 웹 페이지 주소'

• 요청에서 주로 씀
• 이를 이용해 '유입 경로 분석' 가능함
• 현재 요청된 페이지의 이전 웹 페이지 주소

🎉 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

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보..)
• 요청에서 사용
  -> 어떤 브라우저에서 주로 장애가 발생하나 확인 ㅇ
  -> 통계

---

특별한 정보

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

🤔 이 중에 중요한 애들만 언급해보자면..

.
.
.

✨ Host _ ['요청한' 호스트 정보(도메인)]

• 요청에서 사용
• 필수
• 하나의 서버가 여러 도메인을 처리해야 할 때
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 -> 여러 애플리케이션이 켜져 있을 때 (ex 영상, 노래,, 등)

✨ Location _[페이지 리다이렉션]

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (Redirect)
• 201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

---

인증

1. Authorization

클라이언트 인증 정보를 서버에 전달

Authorization: Basic xxxxxxxxxxxxxxxx

인증에도 여러 종류가 있다.

2. WWW-Authenticate

리소스 접근시 필요한 인증 방법 정의

• 리소스 접근시 필요한 인증 방법 정의
• 401 Unauthorized 응답과 함께 사용
  -> 인증이 안되었기에 이런 '인증 방법'을 구상하여 보내라 하고 알려줌
  예시) WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

---

쿠키

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

왜 쿠키가 필요한디? _ Stateless

📢 여러분 클라이언트는 '단기 기억 상실증'... 서버와 요청-응답 주고 받으면 연결 끊어지잖아요!!! 🤦‍♀️

다시 떠올리자 Stateless

• HTTP 는 무상태 프로토콜 (Stateless)
• 연결이 끊어지고 클라이언트가 다시 요청해도, 서버는 이전 요청을 기억하지 못한다... 💦💦

아 그러면 모든 요청마다 '사용자 정보'를 넘기면 되는거 아닌가요? 🤷‍♂️😎😎

그렇게 되면... 얼마나 수고스러울지,,, 아는가?
그리고 브라우저를 완전히 종료하고 다시 열면...??

쿠키의 등장

1. 서버에서 '사용자' 정보를 쿠키에 담아 클라이언트에게 보내주면
2. 클라이언트는 쿠키 저장소에 저장한다.

그러고 매번 클라이언트는 '쿠키 저장소'에서 꺼내서 담아 서버에 보내주지... 👍👍
=> 그러면 모든 요청에 '쿠키 정보'가 자동으로 포함돼

쿠키를 좀 더 구체적으로

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

• 사용처
  • 사용자 로그인 세션 관리
  • 광고 정보 트래킹
• 쿠키 정보는 항상 서버에 전송됨
  • 단점) 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 '웹 스토리지'
  -> (localStorage, sessionStorage) 참고
• 주의!
  • 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

쿠키 내에 무엇이?

쿠키 - 1.생명주기 (Expires, max-age)

Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
=> 만료일이 되면 쿠키 삭제

• max-age=3600 (3600초 유지)
• 세션 쿠키: 날짜 생략시 적용
  -> (만료) 브라우저 종료시
• 영속 쿠키 : 날짜 입력시
  -> (만료) 해당 날짜까지

쿠키 - 2. 도메인

예) domain=example.org

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

쿠키 - 3. 경로

예) path=/home

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

쿠키 - 4. 보안

Secure, HttpOnly, SameSite

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

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

• SameSite [최근에 나옴]
  • XSRF 공격 방지
  • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송