1. HTTP 헤더
HTTP 헤더는 HTTP 메시지에 추가적인 정보를 제공하여 통신을 원활하게 합니다. 이러한 헤더들은 요청과 응답 모두에 사용됩니다. 이를 통해 메시지 바디의 내용, 길이, 압축 여부, 인증, 캐시 관리 등의 부가 정보를 전달할 수 있습니다.
(1) HTTP 헤더의 구조
HTTP 헤더는 다음과 같은 구조를 가집니다
(field-name은 대소문자를 구분하지 않음. OWS는 띄어쓰기를 허용)
(2) HTTP 헤더 표현
현재 HTTP/1.1 표준에서는 메시지 본문(Message Body)을 통해 표현 데이터(Representation Data)를 전달합니다. 이에 따라 표현 데이터를 해석하기 위한 정보를 제공하는 표현 헤더(Representation Header)가 사용됩니다. 표현 헤더는 표현 데이터를 해석하는 데 필요한 정보를 제공합니다.
메시지 본문은 표현 데이터를 전송하는데 사용됩니다. 이는 요청이나 응답에서 전달할 실제 데이터를 포함합니다.
여기서 표현이라는 것은 쉽게 설명하자면, 예를 들어 회원이라는 리소스를 전송해야할 때, html이라는 형식으로 전송할 것인지, Json으로 전송할 것인지, xml로 전송할 것인지 등의 경우가 있습니다. 즉 서버가 서로 정보를 주고 받을때, 서로 간의 이해할 수 있는 형식으로 보내는 것입니다. 이때 데이터를 html로 표현한다, xml로 표현한다, json으로 표현한다는 식으로 이해할 수 있습니다.
(3) 표현과 관련된 헤더
주요 표현 헤더는 다음과 같습니다. 이러한 표현 헤더는 전송과 응답 모두에서 사용됩니다.
- Content-Type: 표현 데이터의 형식을 나타냅니다.
- Content-Encoding: 표현 데이터의 압축 방식을 나타냅니다.
- Content-Language: 표현 데이터의 자연 언어를 표시합니다.
- Content-Length: 표현 데이터의 길이를 나타냅니다.
1. Content-Type
Content-Type은 Content-Body에 들어가는 것이 무엇인지를 나타냅니다.
예를 들어, 위 그림에서 Content-Type이 html로 설정되어있을 때는 Body의 형식이 <html> 로, Json으로 설정되어있을 때는 json 형식으로 되어있습니다.
예시로 text/html; charset=utf-8, application/json, image/png 등이 있습니다.
2. Content-Encoding
표현 데이터를 압축하기 위해 사용됩니다.
데이터를 전달하는 쪽에서 압축을 해서 보내면 무슨 방식으로 압축을 했는지에 대한 인코딩 헤더를 추가하게 됩니다. 그러면 데이터를 읽는 쪽에서 인코딩 헤더를 참고하여 압축을 해제할 수 있습니다.
3. Content-Language
표현 데이터의 자연 언어를 표현하는 것입니다.
쓰여진 언어가 영어인지, 한국어인지를 확인할 수 있습니다.
4. Content-Length
표현 데이터의 길이를 나타냅니다. 바이트 단위로 표시됩니다.
2. 헤더 내의 정보
(1) 일반 정보
1. Form
유저 에이전트의 이메일 정보입니다. 일반적으로 잘 사용하지는 않지만, 검색 엔진 같은 곳에서 사용합니다.
2. Referer
현재 요청된 페이지의 이전 웹 페이지 주소를 나타냅니다. 자주 사용되는 헤더 정보입니다.
A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청하게 됩니다, 이를 통해서 유입 경로 분석이 가능합니다. (블로그 유입 경로 등)
(참고로 referer는 단어 referrer의 오타입니다. 오타가 일반화되어 수정하지 못하고 있는 상황)
3. User-Agent
유저 에이전트 애플리케이션 정보입니다.
예) useragent: 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
클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)를 파악할 수 있습니다. 이를 통해 어떤 종류의 브라우저에서 장애가 발생하는지 파악이 가능합니다,
4. Server
요청을 처리하는 오리진 서버의 소프트웨어 정보를 나타냅니다.
예) Apache/2.2.22 (Debian)
5. Date
메시지가 발생한 날짜와 시간을 나타냅니다.
예) Date: Tue, 15 Nov 1994 08:12:31 GMT
(2) 특별한 정보
1. Host : 요청한 호스트 정보(도메인)
Host 정보는 매우 중요한 필수 값입니다.
하나의 서버가 여러 도메인을 처리해야 할 때나 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 구분을 해주는 것입니다.
만약, 호스트가 없다면 GET/hello라는 요청을 보낼 때, IP로만 통신하기 때문에 어디로 요청을 보내야할지 알 수가 없습니다. 그래서 host 필드를 통해 해당하는 도메인으로 전달합니다.
2. Location: 페이지 리다이렉션
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트) 하게 됩니다.
상태코드 201 (Created)에서의 Location 값은 요청에 의해 생성된 리소스 URI이고, 3xx (Redirection)에서의 Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킵니다.
3. Allow: 허용 가능한 HTTP 메서드
만약 아래처럼 Allow가 되어있다면,
• Allow: GET, HEAD, PUT
그 외의 메서드는 405 (Method Not Allowed)가 반환되게 됩니다. 많이 사용하는 정보는 아닙니다.
3. 인증과 관련된 헤더
1. Authorization
클라이언트 인증 정보를 서버에 전달하는 정보입니다.
Authorization: Basic xxxxxxxxxxxxxxxx 같은 형식으로 제공되는데, 인증 방식에 따라 많이 다르기 때문에, 어떤 인증방식을 택하느냐에 따라서 해당하는 형식을 확인할 수 있습니다.
2. WWW-Authenticate
리소스 접근시 필요한 인증 방법 정의해주는 것입니다. 401 Unauthorized 응답과 함께 사용됩니다.
만약 인증방식이 잘못되면 아래 처럼 이런 식으로 인증을 할 수 있다는 가이드를 제공합니다.
• WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"
4. 쿠키
(1) 쿠키 헤더
쿠키를 사용할 때에는 두 가지 헤더를 사용합니다.
- Set - Cookie : 서버에서 클라이언트로 쿠키 전달
- Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
(2) 쿠키가 탄생한 배경
쿠키를 사용하지 않는 경우를 살펴보겠습니다.
만약 웰컴 페이지에 아무 정보없이 들어가게 되면 손님으로 반환이 됩니다.
홍길동으로 로그인해서 들어가면 홍길동 님으로 반환이 됩니다.
그런데 로그인 후 웰컴 페이지 접속하면 다시 홍길동이란 정보 사라지고 손님이 됩니다.
이것은 HTTP가 무상태 프로토콜이기 때문입니다.
클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어집니다. 그리고 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못합니다. 즉 클라이언트와 서버는 서로 상태를 유지하지 않는 것입니다.
(3) 쿠키의 등장
그래서 대안으로 쿠키가 등장합니다.
로그인을 하게되면 서버는 쿠키 저장소에 user = 홍길동이라는 정보를 저장하게 됩니다.
이후 다시 웰컴 페이지에 접근하면, 클라이언트가 요청시마다 쿠키의 정보를 조회해 user=홍길동을 찾아냅니다.
쿠키의 주 사용처는 사용자 로그인 세션 관리나 광고 정보 트래킹 시에 사용됩니다.
그리고 쿠키 정보는 항상 서버에 전송되기 때문에 네트워크 트래픽을 추가로 유발한다는 단점이 있습니다. 그래서 세션 id, 인증 토큰과 같은 최소한의 정보만 사용하는 것이 좋습니다. 만약 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage)를 참고할 수 있습니다.
(4) 쿠키의 형식
쿠키의 형식은 아래와 같습니다.
set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec 2020 00:00:00 GMT; path=/;domain=.google.com;Secure
1. 생명주기 (Expires, max-age)
Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT 와 같은 형식으로 정합니다. 만료일이 되면 쿠키가 삭제됩니다.
Set-Cookie: max-age=3600 (3600초) 과 같은 형식으로 정해질 때는, 0이나 음수를 지정하면 쿠키가 삭제됩니다.
생명주기 관점에서 쿠키는 두 가지로 나눠볼 수 있는데,
세션 쿠키는 만료 날짜를 생략하면 브라우저 종료시까지만 유지됩니다. 반면 영속 쿠키는 만료 날짜를 입력하면 해당 날짜까지 유지됩니다.
2. 도메인 (Domain)
domain=example.org
명시한 문서 기준 도메인 + 서브 도메인 포함합니다.
domain=example.org를 지정해서 쿠키를 생성합니다. example.org는 물론이고, dev.example.org도 쿠키 접근이 가능합니다.
만약 생략을 하게 되면 현재 문서 기준 도메인만 적용이 됩니다.
예를 들어, example.org 에서 쿠키를 생성하고 domain 지정을 생략하면 example.org 에서만 쿠키 접근이 가능하고, dev.example.org와 같은 하위 도메인에서는 쿠키 접근을 할 수 없습니다.
3. 경로(Path)
path=/home
이 경로를 포함한 하위 경로 페이지만 쿠키에 접근이 가능합니다. 일반적으로 path=/ 루트 로 지정합니다.
만약 path=/home 로 지정하면, /home, /home/level1, /home/level1/level2이 모두 가능합니다. /hello는 불가능합니다.
4. 보안 (Secure, HttpOnly, SameSite)
• Secure : 쿠키는 http, https를 구분하지 않고 전송합니다. Secure를 적용하면 https인 경우에만 전송이 가능합니다.
• HttpOnly : XSS 공격 방지를 위한 것입니다. 자바스크립트에서 접근 불가능 하고, HTTP 전송에만 사용됩니다.
• SameSite : XSRF 공격 방지를 위한 것입니다. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송합니다.
참고자료
[인프런 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식]
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
모든 개발자를 위한 HTTP 웹 기본 지식 강의 - 인프런
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., [사진] 📣 확인해주세요!본 강의는 자바 스프링 완전 정복 시리즈의 세 번째 강의입니다. 우아한형제들 최연소 기술
www.inflearn.com
'Backend > HTTP' 카테고리의 다른 글
| [HTTP] HTTP 상태코드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 6) (0) | 2023.04.25 |
|---|---|
| [HTTP] HTTP 메서드 활용 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 5) (0) | 2023.04.25 |
| [HTTP] HTTP 메서드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 4) (0) | 2023.04.21 |
| [HTTP] HTTP 기본 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 3) (0) | 2023.04.20 |
| [HTTP] URI와 웹 브라우저 요청 흐름 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 2) (0) | 2023.04.18 |
