HTTP 웹 기본 지식 (7)

김영한님의 HTTP 웹 기본지식을 들으며 정리하였습니다.

표현은 요청이나 응답에서 전달할 실제 데이터를 의미함. 표현 헤더에서는 표현 데이터를 해석할 수 있는 정보가 제공됨.

Content-Type : 표현 데이터의 형식 - media type(application/json , text/html)이나 문자 인코딩(charset=utf-8) 등의 정보
Content-Encoding : 표현 데이터의 압축 방식 - 표현 데이터를 압축할 때 사용함(gzip 등). 뭘로 압축했는지 알려줘야 받는 곳에서 압축해제 가능
Content-Language : 표현 데이터의 자연 언어 - ko, en, en-US 등 어느나라 언어인지를 표기해줌
Content-Length : 표현 데이터의 길이 - 바이트단위

클라이언트가 원하는 표현이 있으니 그것에 맞춰서 데이터 달라고 요청하는 거임. 근데 서버가 최대한 맞춰주는 거지, 못맞출수도 있음. 협상 헤더는 Request에서만 사용됨.

ex1) 외국에서 이벤트하는 페이지에 Accept-Language : ko 라고 보냄. 그럼 한국어를 지원하는 서버라면 ko로 맞춰서 보내줌. 하지만 없다면 기본으로 설정된 언어로 보냄.(나라마다 다르겠지)

ex2) 근데 만약 한국어가 없다면? 기본 언어가 독일어고 지원하는 언어가 영어뿐인 서버라면 우선순위를 따져서 보냄. 다음 설명을 참고.

방식1. Quality Values가 클수록 높은 우선순위. (0~1값)

방식2. 구체적인 것을 우선한다. 다음과같이 text에 얼마나 많은 정보가 있는지처럼.

그러면 위 사진에서 볼때 Accept는 4순위인 것이다.

방식3. 구체적인 것을 기준으로, 미디어 타입을 맞춘다.

단순 전송 : Content-Length를 알고있을 때 한번에 요청하고 한번에 쭉 받기
압축 전송 : 이렇게 전송할 땐 뭘로 압축했는지 알아야 푸니까 Content-Encoding을 함께 알려줘야함.
분할 전송 : 용량 큰거 chunk별로 나눠서 보내는 것. 이때는 Content-Length를 보내면 안됨! 각 chunk마다 길이가 다르기도 하고, 애당초 쪼개서 보내니까 전체 길이를 예측할 수도 없음.
범위 전송 : 중간에 전송이 끊겼을 때, 어디부터 다시 전송해달라고 요청함.

HTTP 헤더에 있는 정보 관련 헤더들임

From (요청) : 유저 에이전트의 이메일 정보 (잘안씀)
Referer (요청)★ : 이전 웹 페이지 주소
- 어떤 화면에서 타고 들어왔는지를 나타냄. naver에서 hello를 검색했으면 referer는 naver인거고, 나무위키에서 검색했으면 namu가 찍혀있겠지.
- 이걸 통해서 유입 경로를 분석할 수 있음.
- 웃긴건 referrer가 맞는거라 referer는 오타임.
User-Agent (요청) : 유저 에이전트 애플리케이션 정보
- 유저의 애플리케이션 정보를 나타냄(크롬, 엣지 ...) 그래서 특정 브라우저에서만 오류가 나는 이런 상황을 파악하기 쉬움. 어떤 브라우저를 많이 쓰는지 통계정보 같은 것도 파악할 수 있음.
Server (응답) : 요청을 처리하는 origin 서버의 소프트웨어 정보 (origin 서버 : 캐시, 프록시 이런거 말고 진짜 내 요청 처리해주는 마지막 서버)
Date (응답) : 메시지가 생성된 날짜

Host : 요청한 도메인 정보 명시해줌
- 필수 헤더이다.
- 하나의 서버거 여러 도메인을 처리해야할 때 사용됨. → 하나의 IP에 여러 도메인이 적용될 때
- 그래서 이 IP에 연결된 여러 도메인중에 어디로 가라는 걸 표시해주는 거임. 12.23.46.79에서 abc.com으로 가거라
Location : 페이지 리다이렉션
- 3XX 응답 결과에 Location이 있다면 해당 위치로 redirect 하게 설정
Allow : 허용 가능한 HTTP 메서드 (잘 안씀)
- 구현해놓은 애들 누군지 명시해주는 거임. GET, PUT만 써져있으면 POST는 못받음
Retry-After : 유저가 기다려야 하는 시간
- 서비스가 언제까지 불가능한지 명시해줌. 복구 시간 불명확하므로 쓰기 어려움.

쿠키 안쓰는 경우) 로그인하고 다른 페이지 갔을 때 로그인한 정보가 안넘어가서 로그인 안한 사람이 되어버린다. HTTP가 Stateless이기 때문에 연결이 끊어지면 서버가 이전 요청을 기억할 방법이 없다.

▶ 만약 이를 해결하고자 모든 요청에 사용자 정보를 담아서 요청하면?? GET /mainPage userName=신짱구 HTTP/1.1 이렇게 해버리면 보안도 당연히 문제고, 개발도 어려움 ... 이를 해결하고자 쿠키를 도입

쿠키를 사용하는 상황

쿠키는 "항상" 서버에 전송된다.

항상 서버에 전송하므로 네트워크 추가 트래픽 발생. 그래서 로그인 관련해서 세션 id나 토큰 등을 최소한으로 쿠키로 사용. 단, 보안에 민감한 주민번호, 신용카드 정보 등은 쿠키 X
요청할때마다 보내기 싫고, 클라이언트쪽에서 정보를 들고있고 싶다면 웹 스토리지에 저장함.

쿠키의 종류

쿠키 쓸 곳 지정 - 도메인 / 경로

시 쓰는 개발자