ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등
2) HTTP BODY
RFC7230~7235 등장
엔티티(Entity) -> 표현(Representation)
표현 (요청이나 응답에서 전달할 실제 데이터) = 표현 헤더 + 표현 데이터
메시지 본문(message body)를 통해표현 데이터전달
표현 헤더는표현 데이터를 해석할 수 있는 정보제공
2 . 표현
Content-Type : 표현 데이터의 형식
Content-Encoding : 표현 데이터의 압축 방식
Content-Language : 표현 데이터의 자연 언어
Content-Length : 표현 데이터의 길이
1) Content-Type
표현 데이터의 형식 설명
미디어 타입, 문자 인코딩
text/html; charset=utf-8application/json
2) Content-Encoding
표현 데이터 압축을 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 곳에서 인코딩 헤더의 정보로 압축 해제
ex) gzip, deflate, identity
gzip
3) Content-Language
표현 데이터의 자연 언어
클라이언트에서 언어를 선택하는 부가 작업 가능
ko(한국어)en(영어)
4) Content-Length
표현 데이터의 길이
바이트 단위
단, Transfer-Encoding(전송 코딩)을 사용하면 Content-Length 사용X
3 . 콘텐츠 협상
- 클라이언트가 선호하는 표현 요청
Accept: 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연 언어
- Accept-Language
1) Accept-Language 적용 전
한국어 브라우저로 외국에 있는 /event 에 접속 요청을 보내면, 서버는 클라이언트가 어떤 언어를 요청하는지 알 수 없기 때문에, 기본 영어(en)로 브라우저에 응답한다.
2) Accept-Language 적용 후
한국어 브라우저로 외국에 있는 /event 에 Accept-Language: ko (한국어 선호)로 접속 요청을 보내면,
서버는 기본 영어 외에 한국어를 지원하므로 한국어(ko)로 브라우저에 응답한다.
3) Accept-Language 복잡한 예시
한국어 브라우저로 외국에 있는 /event 에 Accpet-Language: ko (한국어 선호) 로 접속 요청을 보내면,
서버가 한국어를 지원하지 않으므로 기본 독일어(de)로 브라우저에 응답한다.
-> 기본 언어가 아닌 영어로 응답을 받고 싶다면, 우선순위가 필요하다!
- 협상과 우선순위
1) Quality Values(q)
Quality Values(q) 값의 범위: 0~1(생략하면 1)
클수록높은 우선순위
한국어 브라우저로 외국에 있는/event 에 Accept-Language: ko-KR (한국어 우선순위 1), ko;q=0.9,en-US;q=0.8,en;q=0.7로 접속 요청을 보내면, 서버가 한국어를 지원하지 않으므로 다음 우선순위인 영어(en)로 브라우저에 응답한다.
클라이언트에서 요청한 text/html;level의 우선순위가 가장 높고, 서버가 해당 미디어 타입을 지원하므로 text/html;level 미디어타입으로 응답한다.
4 . 전송 방식
단순 전송
압축 전송
분할 전송
범위 전송
1) 단순 전송
Content-Length 설정
데이터 전체를 한 번에 보낼 때 사용
2) 압축 전송
Content-Encoding 설정
전송해야하는 데이터가 커서 압축해서 보낼 때 사용
3) 분할 전송
Transfer-Encoding:Chunked 설정
Content-Length 설정은 하지 않는다
대용량 데이터를 클라이언트에 보낼 때, 요청이 모두 처리되기 전까지 총 크기를 알 수 없을 때 사용
아래 그림에서는 5바이트씩 나눠서 전송하고, r\n\ 은 분할 전송의 끝을 나타낸다
4) 범위 전송
Range 설정해서 요청 -> Content-Range 설정해서 응답
어떠한 이유로 중간에 재요청해야할 때, 범위를 지정하여 사용
5 . 일반 정보
From
Referer
User-Agent
Server
Date
1) From (요청)
클라이언트의 이메일 정보
검색 엔진같은 곳에서 주로 사용
일반적으로 잘 사용X
2) Referer (요청)
현재 요청된 페이지의 이전 웹 페이지 주소
많이 사용
A->B로 이동하는 경우 B를 요청할 때,Referer:A를 포함해서 요청함
유입 경로 분석에 사용
3) User-Agent (요청)
클라이언트 애플리케이션 정보
장애가 발생하는 브라우저 파악, 통계 정보 사용
4) Server (응답)
요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
ORIGIN 서버: 실제로 응답을 보낸 서버(HTTP 요청을 보내면, 실제로 많은 프록시 서버를 거쳐 응답을 받게된다)
5) Date (응답)
메시지가 발생한 날짜와 시간
6 . 특별한 정보
Host
Location
Allow
Retry-After
1) Host (요청)
요청한 호스트 정보(도메인)
매우 중요!
하나의 서버가 여러 도메인을 처리해야 할 때(하나의 IP 주소에 여러 도메인이 적용되어있을 때) 사용
가상 호스트를 통해 여러 도메인을 한 번에 처리할 수 있는 서버가 있다고 하자. 만약 클라이언트가 Host를 지정하지 않고 서버에 /hello 요청을 보내는 경우, 서버는 /hello가 aaa.com, bbb.com, ccc.com 중 어떤 도메인에 관한 요청인지 구분할 수 없다.
이 경우 클라이언트가 Host를 지정하고 서버에 /hello 요청을 보내면, 서버는 Host의 aaa.com에 관한 요청인지를 알 수 있다.
2) Location (응답)
페이지 리다이렉션
3xx(Redirection)의 Location 값: 요청을 자동으로리다이렉션하기 위한 대상 리소스 (이동할 위치)
201(Created)의 Location 값: 요청에 의해 생성된 리소스의 URI
3) Allow (응답)
허용 가능한 HTTP 메서드
405(Method Not Allowed) 에서 응답에 포함해야 한다
서버에서 많이 구현x
4) Retry-After
클라이언트가 다음 요청을 하기까지 기다려야 하는 시간
503 (Service Unavailable): 서비스가 언제까지 불가한지 알려줄 수 있다
날짜, 초단위 표기
7 . 인증
1) Authorization (요청)
클라이언트 인증 정보를 서버에 전달
value 값은 인증 방식(OAuth)에 따라 다양하다
ex) Authorization: Basic xxxxxxxxxxxxx
2) WWW-Authenticate (응답)
리소스 접근시 필요한 인증 방법 정의
401 Unauthorized 응답과 함께 사용
8 . 쿠키
Set-Cookie : 서버 -> 클라이언트 쿠키 전달 (응답)
Cookie : 클라이언트가 서버에서 받은 쿠키를 저장, 클라이언트 -> 서버 쿠키 전달 (요청)
1) 쿠키 미사용
사용자가 id, password 정보를 담아 서버에 /login 을 POST로 요청하면, 서버는 user 이름을 포함하여 로그인 성공 응답을 한다.
그러나 사용자가 로그인 이후 서버에 /welcome 을 요청하면,서버는 로그인한 사용자임을 구분할 수 없기때문에~손님을 응답한다. 이는 HTTP가 무상태(Stateless) 프로토콜이기 때문이다. 무상태에서는 클라이언트와 서버가 요청, 응답을 주고 받은 후 연결이 끊어지기 때문에 서버는 이전 요청을 기억하지 못한다.
이를 해결하기 위해서서는 요청에 링크와 사용자 정보를 포함해야 한다. 그러나 모든 요청에 사용자 정보를 포함한다면 개발이 어렵고, 브라우저를 종료하고 다시 시작하면 Web Storage에 저장 후 다시 넣어야 하는 단점이 있다.
2) 쿠키 사용
웹 브라우저가 id, password를 담아 POST로 /login을 서버에 요청하면, 서버는 Set-Cookie에 유저 정보를 담아 클라이언트에 응답한다. 그 다음 클라이언트 웹 브라우저의 쿠키 저장소에 쿠키를 저장한다.
로그인 이후, 웹 브라우저가 자동으로 Cookie를 담아 /welcome을 서버에 요청하면, 서버는 쿠키를 확인해서 로그인한 유저를 확인하고 응답을 한다.
쿠키를 이용하면, 로그인 이후 웹 브라우저가 요청을 보낼 때 자동으로 쿠키 저장소에서 꺼낸 쿠키를 담아 요청을 보낸다.
쿠키는 항상 서버에 전송된다!
사용자 로그인 세션 관리, 광고 정보 트래킹 등에 사용
그러나 네트워크 트래픽을 추가적으로 유발할 수 있기 때문에, 최소한의 정보만 사용해야 한다
만약 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 참고
보안에 민감한 데이터는 절대 저장하면 안 된다! ex) 주민번호, 신용카드 번호
- 쿠키 접근 제한 방법
1) 생명 주기
expires : 만료 날짜 설정
max-age : 초단위 설정- 쿠키 종류
세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시까지만 유지
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지 (브라우저가 종료되어도 클라이언트 시간이 남아있는 한 유지)
2) 도메인 (domain)
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함 적용 ex) domain=example.org로 지정하면 example.org와 dev.example.org(서브 도메인)도 쿠키 접근 가능
생략: 현재 문서 기준 도메인만 적용 ex) example.org에서 domain을 지정하지 않고 쿠키 생성시, example.org에서만 쿠키 접근이 가능하고, 서브 도메인은 접근 불가능
