HTTP Header 개요
1. 용도
HTTP 전송에 필요한 모든 부가 정보
ex) 메시지 바디의 내용, 미시지 바디의 크기, 압축, 인증, 요청 클라이언트 ...
표준 헤더가 너무 많음
필요시 임의의 헤더 추가 가능
2. 분류
1) RFC2616
헤더 분류
- General Header = 메시지 전체에 적용되는 정보
- Request Header = 요청 정보
= web browser 정보 - Response Header = 응답 정보
= 요청을 받아서 처리하는 정보 - Entity Header = 엔티티 바디 정보
= content Type Message Body와 관련 (JSON이냐 XML 또는 TEXT 길이 등등)
Message Body
메시지 본문은 엔티티 본문을 전달하는데 사용
엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
인티티 헤더는 엔티티 본문의 데이터를 해석
-> html, json, 데이터 길이, 압축 정보 등등
BUT RFC2616 폐기 됨
RFC732x 변화
Entity -> Representation
표현 = 표현 메타 데이터 + 표현 데이터
HTTP BODY
메시지 본문을 통해 표현 데이터 전달
메시지 본문 = payload (실제 Data를 전달)
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
-> HTML, JSON, 데이터 길이, 압축 정보 등등
참고)
-> 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분, 여기서는 생력
표현
ex) 회원이라는 Resource, HTML 이라는 표현으로 전달, JOSON이라는 Data 형태로 전달
- ContentType
표현 데이터의 형식 - Content-Encoding
표현 데이터의 압축 방식 - Content-Langauge
표현 데이터의 자연 언어 - Content Length
표현 데이터의 길이
-
Content Type
미디어 타입, 문자 인코딩
-
Content-Encoding
표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 헤제
-
Content-Language
-
Content-Length
바이트 단위
단) transfer-Encoding을 사용하면 Content-Length를 사용하면 안된다.
협상
클라이언트가 선호하는 표현 요청 (Server가 원하는 우선순위에 맞춰서)
Accept : 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset : 클라이언트가 선호하는 문자 인코딩
Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
Accept-Langauge : 클라이언트가 선호하는 자연 언어
협상과 우선순위
Quality(q) Values(q) 값을 사용
0 ~ 1 클수록 높은 우선순위
생략하면 1이라고 본다
ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
구체적인것 우선
Accept: text/, text/plain, text/plain;format=flowed, /
text/plain;format=flowed > text/plain > text/ > / (우선 순위 높은 순)
전송 방식
Transfer Encoding
Range, Content-Range
단순 전송
한번에 요청 -> 한번에 쭉 받는 방식
압축 전송
용량 감소
분할 전송
File 크기가 클수록 보내는데 시간 많이 든다, 따라서 분할 해서 보내면 시간 감소
범위 전송
범위를 지정해서 요청한다.
일반 정보
From : 유저 에이전트의 이메일 정보
Referer : 이전 웹 페이지 주소
User-Agent : 유저 에이전트 애플리케이션 정보
Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보
Date : 메시지가 생성된 날짜
From
유저 에이전트의 이메일 정보
- 일반적으로 사용 X
- 검색 엔진 같은 곳에서 주로 사용
- 요청해서 사용
Referer
이전 웹 페이지 주소
- 현재 요청 된 페이지의 이전 웹 페이지 주소
- Referer를 사용해서 유입 경로 분석 가능
- 요청에서 사용
User-Agent
- Web browser 정보, client application 정보
- 통게 정보
- 어떤 종류의 브라우저에서 log를 비교해서 장애가 발생하는지 파악 가능
Server
요청을 처리하는 Origin 서버의 소프트웨어 정보
Date
메시지가 발생한 날짜와 시간
특별한 정보
Host
요청에서 사용
필수
하나의 서버가 여러 도메인 처리
하나의 IP 주소에 여러 도메인 적용되어 있을 때
Location
페이지 리다리렉션
웹 브라우저는 3XX 응답 결과에 Location Header 있으면, Location 위치로 자동 이동
Allow
405에서 응답에 포함 되어야 한다.
Allow : GET, HEAD, PUT
Retry-After
유저 에이전트가 다음 요청을 하기 전까지 기다려야 하는 시간
503 : 서비스가 언제까지 불능인지 알려 줄 수 있음
인증
Authorization : 클라이언트 인정 정보를 서버에 전달
WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
-> 401 응답과 함께 사용
쿠키
set-cookie : 서버에서 클라이언트로 쿠키 전달
Cookie : 클라이언트가 서버에서 받은 쿠키를 저장, HTTP 요청시 서버로 전달
쿠키 미사용시
Stateless로 인해 HTTP는 무상태 프로토콜,
클라이언트와 서버가 요청과 응답을 주고 받으면 연결 끊어진다.
클라이언트가 다시 요청하는 서버는 이전 요청을 기억하지 X
계속해서 값을 다 넣어서 보내줘야 한다.
쿠기 사용
예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
사용처
- 사용자 로그인 세션 관리
- 광고 정보 트레킹
쿠키 정보는 항상 서버에서 전송
- 네트워크 트레픽 추가 유발
- 최소한의 정보만 사용
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶다면 webStorage 참고
단 민감한 정보는 저장 X
생명주기
-
expires
만료되면 쿠키 삭제 -
max-age
0이나 음수를 지정하면 쿠키 삭제
세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜 까지 유지
Domain
명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
domain=example.org를 지정해서 쿠키 생성
• example.org는 물론이고
• dev.example.org도 쿠키 접근
생략 : 현재 문서 기준 도메인만 적용
example.org 에서 쿠키를 생성하고 domain 지정을 생략
• example.org 에서만 쿠키 접근
• dev.example.org는 쿠키 미접근
쿠키 경로
이 경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/ 루트로 지정
• path=/home 지정
• /home -> 가능
• /home/level1 -> 가능
• /home/level1/level2 -> 가능
• /hello -> 불가능
쿠키 보안
Secure
- 쿠키는 http, https를 구분하지 않고 전송
- secure를 적요하면 https인 경우에만 전송
HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가
- HTTP 전송에만 사용
SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송
