HTTP 헤더 개요
엔티티 본문: 요청이나 응답에서 전달할 실제 데이터값
엔티티 헤더: 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공
데이터 유형(html, json), 데이터 길이, 압축 정보 등등 그런데
HTTP 표준이 1999년 RFC2616 -> 2014년 RFC7230~7235의 등장으로 엔티티 바디라는 용어가 사라짐
엔티티 -> 표현
표현 = 표현 메타데이터 + 표현 데이터
메시지 본문(페이로드)을 통해 표현 데이터 전달
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
데이터 유형(html, json), 데이터 길이, 압축 정보 등등참고: 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 하지만, 너무 복잡해지므로 생략
왜 표현이라 하는가?
회원과 관련된 정보를 HTML로 전달해준다
-> HTML로 표현해준 것임
DB를 JSON으로 만약 조회
-> 실제 데이터(회원 리소스)가 HTTP에서 전달이 될 때는 HTML or JSON 표현해서 전달할 수 있음표현
실제 리소스는 굉장히 추상적임 -> DB or byte코드 or 파일
이 리소스를 클라이언트 <-> 서버 주고받을때는 필요한 형식으로 바꿔서 정보를 제공
(ex) JSON, HTML, XML
Content-Length: 표현 헤더라기보다는 명확히 하려면 페이로드 헤더라고 구분해야 하지만 복잡함
표현 헤더는 전송, 응답 둘 다 사용 가능
JSON 기본이 UTF-8
표현 데이터 인코딩
표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제표현 데이터의 자연 언어
ex) ko, en, en-US콘텐츠 협상
협상 헤더는 요청시에만 사용한다
클라이언트의 Accept-Language 를 서버가 지원할 경우
클라이언트의 Accept-Language 를 서버가 지원하지 않을 경우
한국인은 그래도 독일어보단 영어가 낫다 -> 서버가 영어를 전달해줘야함.
이때 필요한게 우선순위
1.Quality Values(q) 값이 높은게 우선순위
2.구체적인 것이 우선순위
(드물게)
3.구체적인 것을 기준으로 미디어 타입을 맞춘다
서버가 XML,JSON 둘 다 지원한다는 가정하에,
클라이언트가 원하는 포맷을 요청하면 Accept에 정보를 넣어준다.
==============================================
(번외)
XML vs JSON
: 엔터키가 없는 키보드와 메모장을 이용해서 일정한 형식을 띄는 파일을 만들고 싶을때 가장 널리 쓰이는 형식
XML형식으로 웹을 표현할 수 있게 만든것이 HTML
JSON: 자바스크립트의 객체 표기법
보다 간결하게, 구조화
XML보다 문법오류에 취약하다..
결론: 안정성이 중요시된다 => XML
가벼움을 중시한다 => JSON
==============================================
전송방식
단순 전송 (Content-Length)
컨텐트의 길이를 알 수 있을 때 사용
한 번에 요청하고 한 번에 다 쭉 받는다.압축 전송 (Content-Encoding)
ex) html 파일을 압축
Content-Encoding: gzip -> 정보를 표시해줘야 한다분할 전송 (Transfer-Encoding)
Trasnfer-Encoding: chunked
용량이 크다면 단순 전송보다 효율적일 수 있다.Content-Length 필드는 넣으면 안된다.
범위 전송 (Range, Content-Range)
이미지를 절반 정도 받았다 -> 처음부터 다시 요청하기 아까우니까 범위를 지정해서 정보를 요청할 수 있다.일반 정보
쉽고 단순한 HTTP 정보성 헤더들
From - 유저 에이전트의 이메일 정보
일반적으로 잘 사용되지 않음
검색 엔진 같은 곳에서, 주로 사용
요청에서 사용Referer - 이전 웹 페이지 주소
정말 많이 사용한다
현재 요청된 페이지의 이전 웹 페이지 주소 (???)
=> 들어오게된 계기가 무엇인지 알 수 있다
(유입 경로 분석 가능 -> 데이터 분석)
요청에서 사용
*참고 : referer는 단어 referrer의 오타 ㅋㅋUser-Agent - 유저 에이전트의 애플리케이션 정보
나의 웹 브라우저 정보 or 클라이언트 애플리케이션 정보
서버 입장에서 도움이 많이 된다.
특정 웹브라우저에서 오류가 생기면 로그를 파악하고 어떤 브라우저에서 장애가 발생하는지, 통계를 낼 수 있다.
요청에서 사용Server - 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
ORIGIN server : HTTP 요청을 하면 수많은 프록시서버를 거치는데 진짜 나의 요청이 도달하는 마지막 서버
그 서버의 소프트웨어 정보가 나옴
응답에서 사용Date - 메시지가 발생한 날짜와 시간
응답에서 사용 (과거 스펙에서는 요청에서도 사용)특별한 정보
Host - 요청한 호스트 정보(도메인) (진짜 중요)
하나의 서버가 여러 도메인을 처리해야 할 때
하나의 IP 주소에 여러 도메인이 적용되어 있을 때
Host: aaa.com 헤더를 넣어서 전달
호스트 정보는 필수다 !!!
Location - 페이지 리다이렉션
웹 브라우저는 3xx의 응답 결과에 Location 헤더가 있으면 그 위치로 자동 이동Allow - 허용 가능한 HTTP 메서드
서버에 많이 구현되어 있지 않다 (참고만하자)
405 - (Method Not Allowed) 에서 응답에 포함해야함
Allo: GET, HEAD, PUTRetry-After - 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
503(Service Unavaiable) : 서비스가 언제까지 불능인지 알려줄 수 있다.
날짜와 초단위 표기 둘 다 가능하다.
사용하기가 쉽지않다 인증
인증
Authorization: 클라이언트의 인증 정보를 서버에 전달할 수 있다.
WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의서버 -> 클라이언트 :
"너가 인증을 하고 싶으면 아래와 같은 정보를 참고해서 제대로 된 인증을 만들어라" 라고 반환
쿠키
쿠키 미사용 하면서 내 정보를 기억하길 원한다
-> 모든 요청에 사용자 정보를 포함되도록 개발해야함 + 보안문제
이를 해결하기 위해 쿠키라는 개념이 도입됨
서버로부터 Set-Cookie를 받아 클라이언트 웹 브라우저의 Cookie 저장소에 쿠키를 저장함
클라이언트는 서버에 요청할때 쿠키저장소를 무조건 제일 먼저 찾아봄 (지저분하게 URL에 쿼리 파라미터를 넣을 필요가 없다)
그럼 모든 요청정보에 쿠키를 넣어서 보낸다?? => 보안상 문제 발생
쿠키의 주 사용처
사용자 로그인 세션 관리
광고 정보 트래킹 (이 웹브라우저를 보는 사람이 이러한 광고를 많이 보는구나~)쿠키 정보는 항상 서버에 전송된다
네트워크 트래픽 추가 유발
최소한의 정보만 사용(세션id, 인증 토큰)
서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
(쿠키는 세팅하면 무조건 서버로 보내서 네트워크 부하가 생기기 때문에 웹 스토리지를 참고)
웹 스토리지: 클라이언트 웹브라우저에 저장하고 클라이언트 JS 로직에서만 사용, 서버에는 전송 안할래~
쿠키에는 보안에 민감한 데이터는 절대 저장하면 안된다!!
ex) 주민번호, 신용카드정보 등등쿠키 - 생명주기, 도메인, 경로, 보안
Reference
김영한 님 - 모든 개발자를 위한 HTTP 웹 기본 지식
