HTTP 헤더

헤더필드의 구성

헤더필드에는 HTTP 전송에 필요한 모든 부가정보가 들어있다. 예를 들면, 메세지 바디 내용, 크기, 압축 방법, 인증, 서버 정보 등등...이 있다.

표현 헤더 (전송, 응답)

표현 헤더는 표현 데이터(메세지 바디)를 해석할 수 있는 정보를 제공한다.

• Content-Type : 표현 데이터의 형식
• Content-Encoding : 표현 데이터의 압축 방식
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이

Content-Type

표현 데이터의 형식을 설명한다.

ex)

• text/html; charset=utf-8
• application/json
• image/png

Content-Encoding

표현 데이터가 어떻게 압축되었는지를 설명한다. 데이터를 받는 쪽에서 이 정보로 압축을 해제한다.

ex)

• gzip
• deflate
• identity

Content-Language

표현 데이터가 어떤 언어로 구성되었는지 설명한다.

ex)

• ko
• en
• en-US

Content-Length

표현 데이터의 길이를 바이트 단위로 설명한다.

** Transfer-Encoding(메세지를 여러개로 쪼개서 보내는 방식)을 사용하면 Content-length를 사용하면 안된다.

협상 헤더 (요청)

클라이언트에서 서버로 요청 메세지를 보낼 때, 클라이언트가 선호하는 표현 형식을 요청하는 것이다. 우선순위를 설정할 수 있다.

• Accept : 클라이언트가 선호하는 미티어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

Accept-Language 예시

0~1 사이 숫자로, 클 수록 높은 우선순위를 갖는다.

위 예시에서는, 기본으로 독일어를 지원하고, 영어도 지원하는 서버에 GET 요청을 보내는데, 이 때, 클라이언트가 설정한 언어의 우선순위는 ko-KR, ko, en-US, en 순이다. (q=1은 생략). 따라서, 서버에서 지원 가능한 en으로 응답 메세지를 보낸다.

헤더의 일반 정보

• User-Agent
• From
• Referer
• Server
• Date

User-Agent (요청에서 사용)

유저 에이전트의 애플리케이션 정보로, 서버에 접근하는 웹 브라우저 같은 애플리케이션의 정보이다.
ex) Chrome/86.0.4240.183

From (요청에서 사용)

유저 에이전트의 이메일 정보로, 잘 사용하지 않는다.

Referer (요청에서 사용)

현재 요청된 페이지의 이전 웹 페이지 주소이다. Referer를 이용하여 유입 경로를 분석할 수 있다.
ex) www.google.com에서 hello를 검색하고 위키백과에 들어가면 위키백과 웹사이트에서 Referer는 www.google.com이다.

Server (응답에서 사용)

서버로 HTTP 요청을 보내면 중간에 많은 프록시 서버를 거치게 되는데, 클라이언트가 보낸 요청을 실제 처리하는 서버인 origin서버의 소프트웨어 정보이다.

Date (응답에서 사용)

메세지가 발생한 날짜와 시간을 나타낸다.

헤더의 특별한 정보

• Host
• Location
• Allow
• Retry-After

Host

하나의 서버에서 여러 도메인을 처리할 경우가 았다. 이 때, 요청한 호스트의 정보를 넣어야 한다.

Location

응답 상태코드 201에서는 요청에 의해 생성된 리소스의 URI가 Location에 있고, 상태코드 300번대에서는 Location 값으로 리다이렉트한다.

인증

클라이언트의 인증 정보를 서버에 전달하는 것이다.

• WWW-Authenticate : 401 Unauthorized 응답과 함께 사용한다. 서버에서 인증 오류가 났을 때, 리소스 접근 시 필요한 인증 방법에 대한 정의를 알려준다.

쿠키

HTTP는 무상태 프로토콜이기 때문에, 클라이언트와 서버가 요청을 주고받으면, 연결이 끊어진다. 서버는 클라이언트의 상태를 저장하지 않는다. 이 문제를 해결하기 위해 쿠키를 사용한다.

쿠키 생성과 유지 동작

쿠키 정보는 항상 클라이언트에서 HTTP 요청을 할 때마다 서버로 항상 전송된다. 따라서, 네트워크 트래픽을 추가 유발하고, 보안에 문제가 생길 수 있다. 따라서, 최소한의 정보(세션id, 인증 토큰)만 쿠키 정보로 저장해야 한다.

쿠키 제약

• 쿠키 생명주기 설정
• 도메인 설정
• 경로 설정
• 보안 설정

쿠키 생명주기 설정

• Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT -> 만료일과 시간 설정
• Set-Cookie: max-age=3600 (3600초) -> 쿠키 유지 시간 설정(밀리세컨드 단위)
  ** 만료 날짜를 지정하지 않으면 브라우저 종료시까지만 쿠키 유지(세션 쿠키)

도메인 설정

• domain=example.org -> 도메인을 명시한 경우는 명시한 도메인 + 서브 도메인을 포함하여 쿠키를 생성한다. dev.example.org도 쿠키 접근할 수 있다.
• 도메인을 명시하지 않은 경우는 현재 문서 기준 도메인만 쿠키를 접근할 수 있다. dev.example.org는 쿠키에 접근할 수 없다.

경로

path=/home -> 이렇게 경로 설정을 하면 해당 경로를 포함한 하위 경로에서만 쿠키에 접근할 수 있다.
일반적으로는 path=/ 와 같이 루트 경로로 설정한다.
ex) path=/home
/home (가능)
/home/example (가능)
/home/example/example2 (가능)
/house (불가능)

보안

• Secure : 쿠키는 http, https를 구분하지 않고 전송한다. Secure를 적용하면 https인 경우에만 전송한다.
• HttpOnly : 해커들이 브라우저에서 자바스크립트를 활용해 쿠키를 탈취할 수 있는데, 이를 해결하기 위해 HttpOnly를 설정하면 자바스크립트에서 쿠키에 접근할 수 없다. (XSS 공격 방지)
• SameSite : 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다. (XSRF 공격 방지)

** 인프런 HTTP 강의 (김영한) 참고