[TIL] 22.12.18 HTTP 헤더 - 일반 헤더(2)

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

HTTP 헤더1 - 일반 헤더

일반 정보

일반적인 정보를 담는 http 헤더들에 대해 알아보자.

 

From

유저 에이전트의 이메일 정보를 담는다. 

일반적으로 많이 사용되지는 않으며, 검색 엔진 같은 곳에서 주로 사용한다.

요청에서만 사용한다.

 

Referer

현재 요청된 페이지의 이전 웹 페이지 주소를 담는다.

A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청을 보낸다. Referer을 통해 유입 경로를 분석할 수 있고, 이는 요청에서 사용한다.

(참고로 referer는 referrer의 오타인데, 과거에 잘못 만들어졌는데 이미 다 쓰기 때문에 수정을 못한 것이라고 한다.)

 

만약 구글에 hello를 검색하고 Hello(Adele)의 나무위키에 들어간다고 해보자.

 

네트워크 탭의 Request Headers를 살펴보면 referer가 google.com으로 되어있는 것을 확인할 수 있다.

 

User-Agent

클라이언트의 애플리케이션 정보(웹 브라우저 정보 등)를 담는다.

예) user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

어떤 브라우저에서 들어오는 지 통계 정보를 뽑거나, 어떤 종류의 브라우저에서 장애가 발생하는 지 파악할 수 있다.

요청에서 사용한다.

 

Server

요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 담는다. (HTTP 요청을 하면 중간에 여러 프록시 서버를 거치게 되는데, 실제로 HTTP 응답을 해주는 서버를 origin 서버라고 한다.)

• Server: Apache/2.2.22 (Debian)
• server: nginx

응답에서 사용한다.

 

Date

메시지가 발생한 날짜와 시간을 담는다.

• Date: Tue, 15 Nov 1994 08:12:31 GMT

응답에서 사용한다.

 

특별한 정보

Host

필수값으로, 중요한 헤더이다.

요청에서 사용하며, 하나의 서버가 여러 도메인을 처리해야 할 때, 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 사용된다.

가상호스트를 통해 여러 도메인(aaa.com, bbb.com, ccc.com)을 한번에 처리할 수 있는 서버가 있다고 하자.

 

Host를 보내지 않으면 /hello로 요청을 보냈을 때 해당 요청이 aaa.com과 관련된 애플리케이션에 들어갈 지, bbb, ccc.com에 들어갈 요청인 지 모른다. (이는 IP로 통신하기 때문이다.)

HTTP 초창기에 이것 때문에 문제가 많았기 때문에 현재는 무조건 넣는 것으로 스펙이 바뀌었다.

 

Host를 지정해주면 서버에서 해당 요청이 aaa.com으로 들어가는 요청인 지 알 수 있다.

 

Location

페이지 리다이렉션과 관련된 정보를 담는다.

• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 2xx(Redirection): Location 값은 요청을 자동으로 리다이렉션하기 위한 대상 리소스를 가리킴(웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 해당 위치로 자동으로 이동)

 

Allow

허용 가능한 HTTP 메서드가 무엇인지 알려준다.

서버에서 해당 URL 경로에서 GET, HEAD, PUT만 지원하는데 클라이언트에서 POST로 요청을 보낼 수도 있다. 그럴 경우 405(Method Not Allowed)에서 Allow 헤더를 응답에 포함해 보내줘야 한다.

 

Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간을 의미한다.

503(Service Unavailable) 상태 코드와 함께 서비스가 언제까지 불능인지 알려줄 수 있다.

• Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
• Retry-After: 120 (초단위 표기)

날짜로 표기하거나, 초단위로 표기할 수 있다.

 

인증

Authorization

클라이언트의 인증 정보를 서버에 전달할 수 있다.

• Authorization: Basic xxxxxxxxxxxxxxxx

인증하는 여러 메커니즘이 있는데, 메커니즘마다 value에 들어가는 내용은 다르다.

 

WWW-Authenticate

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

• WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

접근을 했는데 인증이 제대로 안되거나 문제가 있을 경우 401 Unauthorized 응답과 함께 사용한다. 인증을 하려면 해당 정보들을 참고해 제대로 된 내용을 만들라고 클라이언트에게 알려준다.

 

쿠키

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달

 

쿠키 미사용

처음 /welcome에 접속했다고 해보자.

 

로그인을 하면 서버에서 로그인에 성공했다는 응답을 보낸다.

 

'안녕하세요. 홍길동님'이라는 결과를 예상했지만 이 경우 서버는 /welcome에 접근한다는 것 외에 정보가 없기 때문에 이 사람이 로그인을 한 것인지 확인할 수 없다.

(HTTP는 무상태 프로토콜이다. 지속연결로 어느정도 연결이 유지되기는 하나 이전 요청을 기억하지는 못한다.)

 

대안으로 모든 요청에 사용자 정보를 포함할 수도 있다. 하지만 이렇게하면 모든 요청과 링크에 사용자 정보가 포함되도록 해야 하기 때문에 복잡해진다.

 

쿠키 사용

쿠키를 사용하면 그런 문제들을 해결할 수 있다.

브라우저가 로그인을 하면 서버가 Set-Cookie 헤더에 정보를 넣어 반환한다. 그러면 웹 브라우저의 내부 쿠키 저장소에 Set-Cookie 값을 저장한다.

 

로그인 이후에 다시 /welcome 페이지로 접근하면 웹 브라우저는 자동으로 쿠키 저장소에서 조회해 Cookie에 유저 값을 넣어 보낸다. 이렇게 하면 쿼리 파라미터를 넣을 필요가 없어진다.

 

쿠키는 모든 요청에 쿠키 정보를 자동으로 포함시킨다.

 

사용처

• 로그인 세션 관리

예시에서는 user=홍길동 이라고 하긴 했지만 실제로 유저의 정보를 그대로 내리는 것은 위험하다. 그래서 로그인이 성공되면 서버에서 세션키를 만들어 서버의 데이터베이스에 저장해놓고, 그 id를 클라이언트에게 반환해주는 방식을 사용한다. 클라이언트는 요청을 보낼 때마다 해당 세션 id를 보낸다.

 

• 광고 정보 트래킹

웹 브라우저를 쓰는 사람이 어떤 광고를 보는지 정보를 수집한다.

 

단점

쿠키 정보는 항상 서버에 전송된다. 그렇기 때문에 추가적인 네트워크 트래픽을 유발한다. 따라서 세션 id, 인증 토큰 등 최소한의 정보만 사용하는 것이 좋다. (주민번호나 신용카드 번호 등 보안에 민감한 데이터는 저장하면 안된다.)

 

생명주기 - Expires, max-age

• Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
  • 만료일이 되면 쿠키 삭제(GMT 기준으로 날짜를 넣어줘야 한다)
• Set-Cookie: max-age=3600 (3600초)
  • 유효기간이 지나면 쿠키 삭제(초 단위로 세팅 가능)
  • 0이나 음수를 지정하면 쿠키 삭제
• 세션 쿠키: 만료 날짜를 생략하면 브라우저를 종료할 때까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

 

도메인

쿠키가 사용되는 도메인을 명시할 수 있다(eg. domain=example.org).

 

명시한 문서 기준의 도메인과 서브 도메인에 제공한다.

domain=example.org를 지정해 쿠키를 생성하면 example.org는 물론이고 dev.example.org도 접근할 수 있다.

 

domain을 생략하면 현재 문서 기준 도메인만 적용된다.

example.org에서 쿠키를 생성하고 domain 지정을 생략하면 example.org에서만 쿠키에 접근할 수 있고 dev.example.org에서는 쿠키에 접근할 수 없다.

 

경로 - Path

이 경로를 포함한 하위 경로 페이지만 쿠키에 접근할 수 있음을 의미한다.

일반적으로 path=/ 루트로 지정한다.

 

만약 path=/home으로 지정하면

• /home -> 가능
• /home/level1 -> 가능
• /home/level1/level2 -> 가능
• /hello -> 불가능

 

보안 - Secure, HttpOnly, SameSite

• Secure

일반적으로 쿠키는 http와 https를 구분하지 않고 전송한다. Secure를 적용하면 https인 경우에만 전송한다.

 

• HttpOnly

XSS 공격을 방지하기 위해 사용한다. 자바스크립트에서 원래 쿠키를 접근할 수 있는데, HttpOnly를 사용하면 HTTP 전송에서만 사용할 수 있다.

 

• SameSite

XSRF 공격을 방지한다. 요청한 도메인과 쿠키에 설정된 도메인이 같을 때만 쿠키를 전송하는 것이다.