JArchive 프로그래밍 일기

5. 일반 헤더 

단순한 정보성 헤더에 대해 알아보자.

From 

유저 에이전트의 이메일 정보. 잘 안씀. 검색 엔진 같은 곳에서 크롤링 할 때 주로 쓴다. 

Referer

현재 요청된 페이지의 이전 웹페이지 주소. 엄청 자주 씀. 

Referer를 활용해서 유입 경로를 분석할 수 있다. 

A->B 로 URL이 이동하는 경우, B를 요청할 때 Referer:A를 포함해서 요청한다. 

참고) referer는 referrer의 오타인데. 이미 스펙에 오타 째로 들어가서 범용으로 사용중이다. 

User-Agent 

유저에이전트 애플리케이션 정보 (== 클라이언트 애플리케이션 정보)

서버 입장에서 User-Agent 정보를 활용하면 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있다. 

로그를 비교해서 브라우저 별 통계 정보를 만들 수 있다. 

요청에서 사용하는 헤더다. 

Server 

요청을 처리하는 Origin 서버의 소프트웨어 정보 

HTTP 요청 응답 과정에서 여러 프록시 서버를 거치게 되는데, 실제 요청을 처리해주는 최종 목적지 서버를 origin서버라고 한다. 

응답에서 사용하는 헤더다. 

Date 

메시지가 발생한 날짜와 시간. 응답에서만 사용한다. 

6. 특별한 정보 헤더 

Host 

요청한 호스트 정보(도메인) 

요청에서 사용하는 필수 헤더다. 

하나의 IP 주소에 여러 도메인이 적용되어 있을 때 Host 헤더로 구분하여 서버가 처리할 수 있다. 

가상 호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버가 있다. 여러 애플리케이션이 같은 도메인을 사용할 수 있다. 

Host 헤더를 안쓰면 어떤 문제가 생길까? 

서버가 IP 로만 요청을 인지하면 어느 도메인에 매핑해야 하는 요청인지 알 수 없다.

Location

3xx응답 결과, Location 헤더 필드가 있으면 Location 위치로 리다이렉트 요청한다. 

201의 경우, 생성된 리소스의 URI를 의미한다. 

Allow 

허용 가능한 HTTP 메서드를 적어준다. 실무에서 잘 안씀.

URL경로는 있는데 get, head, put 만 제공하는 경우, 405 코드와 Allow 필드를 응답에 포함해야 한다. 

Retry-After

유저가 다음 요청을 하기까지 기다려야 하는 시간.(날짜 또는 초 단위)

503 코드에서 사용한다. 서비스가 언제까지 불능인지 Retry-After헤더에 시간을 실어서 알려줄 수 있다. 

7. 인증 헤더 

Authorization 

클라이언트 인증 정보를 서버에 전달한다 

인증 매커니즘에 따라 Authorization헤더에 넣을 내용이 달라진다. ex) O-auth, etc 

WWW-Authenticate 

리소스 접근 시 필요한 인증 방법을 정의한다. 

401 오류 발생 시, 이 헤더를 넣어줘야 한다. realm=‘apps’, title=‘example’ 등의 형태를 정의한다. 

8. 쿠키  

쿠키를 안 쓰는 시나리오 

브라우저 : 사용자가 로그인 정보를 서버에 보낸다. 

서버 : 로그인 성공했다고 응답한다. 

브라우저 : '마이페이지' 를 요청한다.  

서버 : (쿠키가 없으니까 요청 주는 사람이 누군지 모름) 누구지? 싶어서 메인 페이지를 응답한다. 

서버가 로그인 사용자를 모르는 이유

HTTP는 무상태 프로토콜이기 때문이다. (Stateless)

클라이언트와 서버가 요청과 응답을 주고받으면 연결이 끊어진다. 

따라서 클라이언트와 서버는 서로 상태를 유지하지 않는다. 

쿠키를 포함한 요청이 아니라면 서버는 이 사람이 로그인 했는지 누군지 모른다. 

그렇다고 모든 요청에 사용자 정보를 포함한다면? 

-> 메뉴를 하나 이동 하더라도 사용자 개인정보를 포함하면, 보안 취약점이 많아진다. 

쿠키를 사용하는 시나리오 

브라우저가 모든 요청에 쿠키를 자동으로 포함하는 방식을 생각해보자. 

로그인 성공 시, 서버는 set-cookie: user=홍길동  이라는 쿠키를 응답해준다. 

서버의 응답을 받은 브라우저는 쿠키 저장소(브라우저 내부)에 이 쿠키를 저장한다. 

브라우저는 요청을 보낼 때 마다 쿠키저장소에서 쿠키를 뒤지고, 있으면 쿠키를 넣어서 HTTP 요청을 보낸다. 

(하지만 이것도 문제점이 있는 방법이다.)

쿠키의 형태

set-cookie: sessionid=abcd123; expires= 26-dec-2021 path=/; domain=google.com

쿠키의 용도

1) 사용자 로그인 세션 관리 
2) 광고 정보 트래킹 

[유의점] 쿠키 정보는 항상 서버에 전송된다!
네트워크 트래픽 추가 유발한다. 그래서 최소한의 정보만 사용해야 한다. (세션 id, 인증 토큰)
서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹스토리지 참고. (localStorage, sessionStorage) 

[주의점]
보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등)

쿠키의 생명주기

expries : 만료일이 되면 쿠기가 자동으로 삭제되게 지정 
max-age : 0이나 음수를 지정하면 쿠키 삭제 

쿠키의 종류 2가지

세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시까지 유지 
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지 

쿠키 도메인

특정 도메인을 명시하면 : 특정 도메인과 서브 도메인을 포함한 요청 시 해당 쿠키를 보낸다. 
만약 도메인을 생략하면 : 현재 문서 기준 도메인만 적용한다. 

쿠키 경로

이 경로를 포함한 하위 경로 페이지만 쿠키를 접근한다. 
일반적으로 path=/ 루트로 지정한다. 
하나의 도메인 내부의 ‘모든 경로’에서 쿠키를 쓰는 것이 일반적이기 때문이다. 

쿠키와 관련된 보안3가지

1) Secure

Secure를 넣으면 https인 경우에만 쿠키를 서버로 전송한다. 

2) HttpOnly

XSS 공격 방지 

자바스크립트에서 쿠키에 접근 불가하도록 제한한다.  
HTTP 전송에만 사용한다. 

3) SameSite

XSRF 공격 방지 
요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 서버로 전송한다. 
SameSite는 가장 최근에 나온 것이라서 브라우저의 지원 여부를 확인하고 사용하자. 

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다.