7. HTTP 헤더 1 - 일반 헤더

이 포스팅은 인프런 김영한 강사님의 <모든 개발자를 위한 HTTP 웹 기본 지식>을 수강하고, 공부하여 글로 정리한 것입니다. 그대로 갖다 붙여넣는 내용이 아니라 기억나는대로 작성한 후 다시 추가적으로 정리하는 방식을 취하고 있기 때문에 틀린 부분이 있을 수 있습니다. 잘못된 점은 짚어주시면 감사하겠습니다.

1. HTTP 헤더 개요

1-1. 용도

HTTP 전송에 필요한 모든 부가 정보를 담기 위함.
예) 메시지 바디 내용/크기, 압축, 인증 등...

표준 헤더가 너무 많음.

필요할 경우, 임의의 헤더를 추가할 수 있다.

1-2. 분류

1. 과거(RFC2616)

분류명	설명	예시
General 헤더	메시지 전체에 적용되는 정보	Connection
Request 헤더	요청 정보	User-Agent
Response 헤더	응답 정보	Server
Entity 헤더	엔티티 바디 정보	Content-Type

HTTP Body

• 메시지 본문(message body) 안에 엔티티 본문(entity body)을 담아서 전송한다.
• 엔티티 본문 : 요청이나 응답에서 전달할 실제 데이터
• 엔티티 헤더 : 엔티티 본문의 데이터를 해석할 수 있는 정보 제공 ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

2. 최신(RFC723x)

엔티티 -> 표현(Representation)

표현 = 표현 메타데이터 + 표현 데이터

HTTP Body

• 메시지 본문(페이로드)을 통해 표현 데이터 전달
• 표현 = 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.

2. 표현

2-1. 표현

리소스를 JSON이라는 형식으로 전송한다 = 리소스를 JSON이라는 데이터 형태의 표현으로 전송한다
표현을 하기 위해서는 헤더에 표현 데이터와 관련한 정보를 작성한다. 표현 헤더는 전송, 응답에 둘 다 사용 가능하다.

• Content-Type: 표현 데이터 형식

• Content-Encoding: 표현 데이터 압축 방식

• Content-Language: 표현 데이터의 자연 언어

• Content-Length: 표현 데이터의 길이

2-2. Content-Type

미디어 타입, 문자 인코딩 등 표현 데이터의 형식을 설명하는 헤더 필드.

예) text/html; charset=utf-8 , application/json , image/png

2-3. Content-Encoding

표현 데이터를 압축하기 위해 주로 사용하기 위한 헤더 필드.

데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가한다. 데이터를 읽는 쪽에서는 이 인코딩 헤더 정보로 압축을 해제한다.

예) gzip(압축 O), deflate, identity(압축 X)

2-4. Content-Language

표현 데이터의 자연 언어를 표현한 헤더 필드.

예) ko, en...

2-5. Content-Length

바이트 단위의 표현 데이터 길이를 나타내는 헤더 필드.

Transfer-Encoding(전송 코딩)을 사용할 경우에는 사용하면 안된다.

3. 협상(콘텐츠 네고시에이션)

3-1. 협상

클라이언트가 선호하는 표현 요청. 협상 헤더는 요청시에만 사용한다.

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

3-2. 우선순위1

클라이언트가 선호하는 표현을 요청했을 때, 서버에 해당하는 것이 없을 경우에 대비하여 우선순위를 설정한다.

0~1 사이의 Quality Values(q) 값을 사용한다. 클수록 높은 우선순위를 갖는다.(생략하면 1)

예시)

GET /event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

이 경우에 우선순위는 다음과 같다:

1. ko-KR;q=1(q생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en;q=0.7

3-3. 우선순위2

구체적인 것이 우선한다.

예시)

GET /event
Accept: text/*, text/plain, text/plain;format=flowed, */*

이 경우에 우선순위는 다음과 같다:

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

3-4. 우선순위3

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

4. 전송방식

분류

• 단순 전송 : 한번에 요청하고 쭉 받는 것
• 압축 전송 : 용량을 줄이기 위해 압축해서 전송. Content-Encoding 입력해주어야 한다.
  • 분할 전송 : Transfer-Encoding. 큰 용량을 분할해서 전송한다. Content-Length를 보내면 안됨.
• 범위 전송 : Range(요청), Content-Range(응답). 범위를 지정해서 요청할 수 있다. 남은 일부만 요청하는 경우 등...

5. 일반 정보

5-1. Form

유저 에이전트의 이메일 정보. 일반적으로 잘 사용되지 않음.

요청에서 사용. 검색 엔진 같은 곳에서 주로 사용.

5-2. Referer

현재 요청된 페이지의 이전 웹 페이지 주소. 요청에서 사용.

A에서 B로 이동하기 위해 B를 요청할 때 referer: A 를 포함해서 요청한다.

유입 경로 분석이 가능하다.

5-3. User-Agent

클라이언트의 애플리케이션 정보(웹 브라우저 정보 등). 요청에서 사용.

통계정보.

어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있다.

5-4. Server

요청을 처리하는 ORIGIN 서버의 소프트웨어 정보. 응답에서 사용.

HTTP 요청을 보내면 중간에 여러 Proxy 서버를 거치게 되기 때문에, 실제로 클라이언트가 요청을 보내는 최종 서버를 ORIGIN 서버라고 함.

5-5. Date

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

6. 특별한 정보

6-1. Host

요청한 호스트 정보(도메인). 요청에서 사용하며, 필수.

하나의 서버가 여러 도메인을 처리해야 할 때 (하나의 IP 주소에 여러 도메인이 적용되어 있을 때)

가상 호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버. 하나의 서버 안에 여러 개의 어플리케이션이 다른 여러 도메인으로 구동되어 있을 수 있다. 이 경우, Host 가 없으면 어떤 도메인으로 요청을 전송해야 하는지 구분할 수 없기 때문에 반드시 넣어주어야 한다.

6-2. Location

페이지 리다이렉션.

웹 브라우저가 3xx 응답 결과에 Location 이 있으면, 해당 위치로 자동으로 이동(리다이렉트)

• 201(Created) : Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection) : Location 값은 요청을 자동으로 리다이렉션하기 위한 대상 리소스를 가리킴

6-3. Allow

허용 가능한 HTTP 메서드

405 Method Not Allowed 에서 응답에 포함해야 함. 많이 구현되어 있지는 않음.

예) Allow: GET, HEAD, PUT => GET, HEAD, PUT만 지원한다.

6-4. Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간. 날짜로 표기할 수도 있고, 초단위로 표기할 수도 있다.

503 Service Unavailable 의 경우, 서비스가 언제까지 불능인지 알려줄 수 있다.

7. 인증

7-1. Authorization

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

7-2. WWW-Authenticate

리소스 접근시 필요한 인증 방법 정의. 인증을 위해서는 해당 헤더의 정보를 참고하여 제대로 된 인증정보를 만들라고 클라이언트로 전달.

401 Unauthorized 응답과 함께 사용한다.

8. 쿠키

8-1. 쿠키를 사용하지 않으면?

쿠키를 사용하지 않는 경우, 로그인을 하더라도 해당 요청에 대해 응답이 완료되면 서버에서는 연결을 끊어버리기 때문에 클라이언트가 로그인한 사용자인지 구분할 수 없다.

Stateless

HTTP는 무상태(Stateless) 프로토콜.
클라이언트와 서버가 요청-응답을 주고 받으면 연결이 끊어진다. 둘은 서로 상태를 유지하지 않는다.
클라이언트가 다시 요청해도 서버는 이전 요청을 기억하지 못한다.

대안

모든 요청과 링크에 사용자 정보를 일일이 포함하여 전달한다면 개발이 어렵고, 보안상 문제도 존재한다.

8-2. 쿠키

과정

1. 클라이언트가 로그인을 요청하면 서버에서는 Set-Cookie 헤더에 담아서 클라이언트로 전달
2. 웹브라우저의 쿠키 저장소에 저장
3. 로그인 이후에 서버에 접근할 때 쿠키 저장소에서 쿠키 값을 꺼내서 헤더에 Cookie 를 만들어 전달한다.
4. 쿠키는 모든 요청에 쿠키 정보를 자동으로 포함시킨다.

정보

• 주사용처 : 사용자 로그인 세션 관리, 광고 정보 트래킹.

• 쿠키 정보는 항상 서버에 전송되므로, 네트워크 트래픽을 유발할 수 있다. 최소한의 정보만 사용하는 것이 좋다.(세션 id, 인증 토큰)

• 서버에 전송하지 않고, 브라우저 내부에 저장하고 싶으면 웹 스토리지를 참고한다.

• 보안에 민감한 데이터는 절대 저장하면 안됨.

생명 주기

세션 쿠키 : 만료날짜를 생략하면 브라우저 종료시까지만 유지

영속 쿠키 : 만료날짜 입력하면 해당 날짜까지 유지

• expire : 만료일 지정. GMT 기준으로 날짜를 입력. 만료일이 되면 쿠키 삭제.

• max-age : 초단위로 세팅. 유효시간이 지나거나 0이나 음수를 지정하면 쿠키 삭제.

도메인 domain

쿠키가 아무 사이트에나 들어가면 안되므로 도메인을 명시.

명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함.

• 예) domain=example.org ====> 해당 도메인뿐 아니라, dev.example.org도 쿠키 접근 가능.

생략 : 현재 문서 기준 도메인만 적용

경로 path

경로를 지정하면 해당 경로를 포함한 하위 경로 페이지만 쿠키에 접근할 수 있다.

일반적으로는 path=/ 루트 패스로 지정.

보안

Secure : 쿠키는 http, https 구분하지 않고 전송하므로, Secure 적용하면 https인 경우에만 전송.

HttpOnly : XSS 공격 방지. 자바스크립트에서 접근 불가. HTTP 전송에만 사용.

SameSite : XSRF 공격 방지. 현재 내가 요청하는 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송.