[매트 스터디] 4주차 HTTP 헤더 1 - 일반 헤더

우아한테크코스 레벨2 에서 매트가 주관한 스터디로, 인프런 김영한님의 강의 모든 개발자를 위한 HTTP 웹 기본 지식 스터디를 진행중이다. 이 포스팅에서는 스터디에 PR을 날릴 내용과 함께 스터디 시간에 얻어간 내용을 적을 예정이다.

---

HTTP 헤더 개요

RFC2616 (과거)

• HTTP 헤더
  • General 헤더: 메시지 전체에 적용되는 정보
  • Request 헤더: 요청 정보 (요청 시에만 존재)
  • Response 헤더: 응답 정보 (응답 시에만 존재)
  • Entity 헤더: Entity 본문을 해석할 수 있는 정보 제공

• HTTP 바디
  • Entity 헤더: Entity 본문을 해석할 수 있는 정보 제공
  • Entity 본문: 실제 전달할 데이터
  • 메시지 본문에는 Entity 본문 내용이 포함돼있음.

RFC7230 (최신)

Entity에 대한 내용을 Representation (표현)으로 변경.

Representation = Representation Metadata + Representation Data

메시지 본문을 payload로 부르기도 한다.

사실상 분류 방식만 변경된 것이고, 대부분의 헤더들은 남아있기 때문에 크게 변경된 건 없다고 봐도 무방하다.

---

표현

• Content-Type: 표현 데이터의 방식 (ex. text/plain, application/json, image/jpg 등)
• Content-Encoding: 표현 데이터의 압축 방법 (ex. gzip, identity(압축안함))
  • 데이터 전달하는 곳에서, 압축 후에 인코딩 헤더 추가
  • 데이터 읽는 곳에서, 인코딩 헤더 정보로 압축 해제
• Content-Language: 표현 데이터의 자연 언어 (ex. ko, jp, en)
• Content-Length: 표현 데이터의 길이

---

콘텐츠 협상

클라이언트가 선호하는 표현을 정해주어 서버 측에서 클라이언트에게 해당 표현으로 전달할 수 있도록 해주는 헤더이다.

따라서 요청 헤더에서만 사용되는 헤더이다.

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

우선순위를 지정해줄 수 있다.

• Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 과 같이 Quality Values (q)를 이용하여 높은 우선순위를 지정해줄 수 있다. q=1의 경우 생략가능.
• 구체적일수록 우선순위가 높다. Accept: text/* 보다 Accept: text/plain이 우선순위가 더 높다.
• 해당 Quality Values가 여러 값이 존재한다면, 구체적인 것을 기준으로 미디어 타입을 맞춰 Quality Values를 맞춘다.

---

전송 방식

• 단순 전송: Content-Length가 명확할 때.
• 압축 전송: Content-Encoding 헤더와 함께 압축하여 전송하는 방법.
• 분할 전송: Transfer-Encoding: chunked 헤더와함께 정보를 분할하여 전송하는 방법. 용량이 매우 클 때 주로 사용된다.
  • Content-Length 헤더 정보를 넣어줘선 안된다. 어차피 Chunked 데이터의 길이 정보들이 존재한다.
• 범위 전송: 클라이언트에서 명시해준 범위의 정보를 전송해주는 방법.

---

정보

• From: 유저 에이전트의 이메일 정보. 일반적으로 잘 사용되지 않음.
• Referer: 이전 웹페이지 주소. (A->B에서의 A) 유입 경로 분석 등, 실제로 굉장히 자주 쓰이는 정보라 한다.
  • 필자의 오타가 아닌, 이미 널리 퍼져서 Referer가 고정돼버린 경우라 한다.
• User-Agent: 유저 에이전트 애플리케이션 정보
  • 통계 정보에 사용됨.
  • 어떤 환경에서 장애가 발생했는지 파악할 때 사용됨.
• Server: 요청을 처리하는 서버의 소프트웨어 정보
  • ex. server: nginx 
  • 응답에서 사용되는 정보
• Date: 데이터가 생성된 날짜
  • 최신 스펙에서는 응답에서만 사용되는 정보라 한다.
• Host: 요청한 호스트 정보 (도메인)
  • 요청에서 사용되며, 필수적인 정보이다.
  • 하나의 서버에서 다중 도메인을 사용할 때, IP 정보만 존재한다면 요청에서 원하는 도메인을 응답해줄 수 없다. -> Host를 찾고, 그 안의 port를 찾는다.
• Location: 페이지 리다이렉션 정보
• Allow: 허용 가능한 HTTP 메서드. 거의 사용하지 않음.
• Retry-After: 유저가 다음 요청을 하기까지 기다려야 하는 시간

---

인증

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

---

쿠키

HTTP는 stateless하므로, 별도의 처리를 하지 않는 이상 로그인 유저 정보를 유지할 수 없다. 그렇다고, 모든 요청 링크에 사용자 정보를 포함해서 보내기엔 보안, 생산성 문제들이 존재한다. 이러한 경우는 또한, 브라우저를 종료할 때 리셋돼버린다.

 

이러한 문제를 해결하기 위해 쿠키 개념이 생겨났다!

출처: 김영한님 강의자료

쿠키 저장소를 이용하여 서버 측에서 쿠키를 만들어준다. 쿠키에는 도메인, 경로, 보안 정보들이 존재한다. 특히 XSS, XSRF 공격 방지를 위한 설정 또한 해줄 수 있다.

 

다만, 쿠키를 사용할 때 주의해야될 점이 존재한다.

• 쿠키 정보는 항상 서버에 전송되므로, 네트워크 트래픽 추가 유발을 최소화하기 위해 최소한의 정보(세션id, 인증 토큰 등)만 저장.
• 서버 전송이 아닌, 웹 브라우저 내부에 저장하고 싶으면 웹 스토리지 이용
• 보안에 민감한 정보는 저장하면 안됨!
• 특히, 세션 id 값이 유출되면 큰일나므로 네트워크 구간 암호화를 위해 HTTPS 에 보관하고, 세션 생명주기를 잘 관리해야 함.

쿠키 생명주기 관련하여 두 가지 종류로 나뉨.

• 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료 시까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

 

로그인 과정 전체 정리

쿠키는 브라우저(클라이언트) 측에서 관리하고, 세션은 서버 측에서 관리하는 정보.

처음 쿠키를 생성할 때, 브라우저는 사이트에서 생성한 쿠키를 URL과 매핑하여 관리. 이후에 로그인 시, 매핑된 쿠키가 있으면 요청에 쿠키를 무조건 포함해서 보냄. 이 때 요청에서의 쿠키 값과 서버의 세션 값을 비교하는 방식으로 로그인 여부 구분

---

이번 주차엔 정보의 나열 느낌이 강했다.

 

실제로 스프링 환경에서의 Acceptance-Language 설정 방법의 경험이 있었어서 더 친숙하게 공부할 수 있었다.

또한, 1주차에 학습했던 port, ip의 지식이 있는 상태로 host에 대해 공부하니까 개념이 확장되는 느낌이 들어 재밌었다.

cs와 개발을 병행할 때 확실히 학습 효율이 높아지는 듯하다.