[Network] 08. HTTP 헤더1 - 일반 헤더

해당 글은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의를 수강하고 정리한 게시글입니다.

HTTP 헤더1 - 일반 헤더

HTTP 헤더는 전송에 필요한 모든 부가정보를 담고 있다.

 

• 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등..

 

현재 표준 헤더는 양이 너무 많고 사용자가 필요 시 임의의 헤더 추가가 가능하다. 그럼으로 이번에는 자주 사용되는 일반적인 헤더들에 대해 알아보자.

참고 : List of HTTP header fields - Wikipedia

표현 헤더

HTTP BODY 예시
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. (표현은 요청이나 응답에서 전달할 실제 데이터이다.)

 

• 예) 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

 

Content-Type

Content-Type는 표현 데이터의 형식을 설명하는 부분이다.

• 예) 미디어 타입, 문자 인코딩
• text/html; charset=utf-8
• application/json

Content-Encoding

Content-Encoding는 표현 데이터 인코딩 방식을 나타낸다.
주로 표현 데이터를 압축하기 위해 사용한다. (데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가하고 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제해 사용한다,)

• 예)
• gzip
• deflate
• identity(압축 되지않고 원본과 동일함을 의미)

Content-Language

Content-Language는 표현 데이터의 자연 언어를 표현한다.

• 예) 애플 홈페이지 같은 곳에서 어떤 언어로 페이지를 사용할 지..
• ko, en, en-US

Content-Length

Content-Length는 표현 데이터의 길이를 나타낸다.
바이트 단위이며 Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안된다.

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

클라이언트가 선호하는 표현 요청(클라이언트의 우선순위에 맞쳐서 표현을 만들어줌.)
(협상 헤더는 요청시에만 사용)

 

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

 

예시) xml보다 json을 우선시 하고싶을 때 사용. (요청전에 서버가 제공하는지 알아야함.)

 

Accept-Language 적용 전

 

Accept-Language 적용 후

 

Accept-Language 적용하였으나 한국어 지원이 안될 경우

독일어는 읽지도 못하고 한국어가 안되면 영어가 더 나을 경우 -> 우선순위 필요

 

 

[협상과 우선순위 1]
Quality Values(q) 값 사용
0~1, 클수록 높은 우선순위 (생략하면 1)

 

예시)

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

 

[협상과 우선순위 2]
구체적인 것이 우선한다.

아래로 갈수록 우선순위가 낮다.

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

 

[협상과 우선순위 3]
구체적인 것을 기준으로 미디어 타입을 맞춘다.
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, /;q=0.5

 

전송 방식

전송에는 다음 4가지 방식으로 분류할 수 있다.

단순 전송

한번에 요청하고 한번에 다 받는 것!

압축 전송

서버쪽에서 압축해서 전송하는 것.(이때는 Encoding방식이 헤더에 명시되어 있어야함.)

분할 전송

덩어리를 쪼개서 보냄(chunked) 끝나고 마지막에는 0 \r\n으로 보냄
(분할 전송때는 Content-Length를 보내면 안됨.)

범위 전송

이미지 같은 걸 받을 때 중간에 받다가 끊기고 다시 요청할 때 범위를 지정해서 요청할 수 있음.

 

 

일반 정보 헤더들

이번에는 단순 정보성 헤더들을 알아보자.

From

유저 에이전트의 이메일 정보를 나타낸다. (일반적으로 잘 사용되지 않음)

• 예) 검색 엔진같은 곳에서 크롤링해 갈 수 있음으로 해당 담당자에게 크롤링 하지말라고 연락할 정보

Referer

현재 요청된 페이지의 이전 웹페이지 주소를 나타낸다.

 

• 예) Referer를 사용해서 유입 경로 분석

 

User-Agent

유저 에이전트 애플리케이션 정보를 나타낸다.(웹브라우저(애플리케이션) 정보라고 이해하면 됨)

 

• 예) 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능.

 

Server

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

 

• 예) Server: Apache/2.2.22 (Debian)

 

Date

메시지가 발생한 날짜와 시간을 나타낸다. (응답에서만 사용하도록 바뀜)

 

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

 

 

특별한 정보

이번에는 특별한 정보를 담고 있는 헤더들에 대해 정리해보자.

Host

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

참고: 필수 값이다.

하나의 서버가 여러 도메인을 처리할 때 Host 정보가 없으면 서버에서 어디로 가야할지 모른다.

Location

웹 브라우저가 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
201은 요청에 의해 생성된 리소스 URI를 가리킴.

 

Allow

허용 가능한 HTTP 메서드를 알려준다..(405 (Method Not Allowed) 에서 응답에 포함해야함)

 

• 예) Allow: GET, HEAD, PUT

 

Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간을 나타낸다.
503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음

 

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

 

 

인증

다음은 인증관련 헤더들의 모음이다.

Authorization

클라이언트 인증 정보를 서버에 전달을 나타낸다.

 

• 예) Authorization: Basic xxxxxxxxxxxxxxxx

 

WWW-Authenticate

리소스 접근시 필요한 인증 방법 정의
401 Unauthorized 응답과 함께 사용한다.(아래와 같이 만들라고 보내줌)

 

• 예) WWW-Authenticate: Newauth realm=“apps”, type=1, title=“Login to \”apps\””, Basic realm=“simple”

 

쿠키

쿠키는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다. 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다. 상태가 없는( stateless ) HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문입니다.

참고 : HTTP 쿠키 - HTTP | MDN

 

사용처)

 

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

 

쿠키 정보는 항상 서버에 전송됨 )

 

• 네트워크 트래픽 추가 유발
• 최소한의 정보만 사용(세션 id, 인증 토큰)
• 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage) 참고

 

주의)

 

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

 

 

쿠키를 사용할 때는 다음 2가지 헤더를 사용한다.

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

 

 

[쿠키 미사용시 예제]

 

처음 welcome 페이지에 접근한다.

 

 

로그인 완료.

 

 

로그인 이후 welcome 페이지에 접근해도 변화가 없다..

 

HTTP는 무상태(Stateless) 프로토콜이다.
클라이언트와 서버가 요처와 응답을 주고 받으면 연결이 끊어진다.(서로 성태를 유지하지 않는다.)

자세한건  [Network] 03. HTTP 기본 침고.

 

 

 

이를 해결하기위한 대안으로는 모든 요청에 사용자 정보를 포함하는 방법이 있다.

하지만, 이는 모든 요청에 사용자 정보가 포함되도록 개발을 해야하고 브라우저를 완전히 종료하고 다시 열면 없어진다.. 이를 해결하기 위한 방법이 쿠키이다.

 

 

[쿠키 사용시 예제]

 

쿠키 사용시 로그인을 하게되면 쿠키 저장소에 로그인 정보가 담긴다.

 

 

로그인 이후 welcome 페이지에 접근하게되면 쿠키 저장소에서 조회해서 접근하게 된다. (이후 모든 요청에 쿠키 정보가 자동으로 포함된다.)

 

생명주기(Expires, max-age)

만료일이 되면 쿠키를 삭제한다.

 

• 예) Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT

 

0이나 음수를 지정하면 쿠키를 삭제한다.

 

• 예) Set-Cookie: max-age=3600 (3600초)

 

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

도메인

명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
domain=example.org를 지정해서 쿠키 생성

 

• example.org는 물론이고
• dev.example.org도 쿠키 접근

 

생략 : 현재 문서 기준 도메인만 적용
example.org 에서 쿠키를 생성하고 domain 지정을 생략

 

• example.org 에서만 쿠키 접근
• dev.example.org는 쿠키 미접근

 

경로

경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/ 루트로 지정

예)

• path=/home 지정
• /home -> 가능
• /home/level1 -> 가능
• /home/level1/level2 -> 가능
• /hello -> 불가능

 

보안

Secure

 

• 쿠키는 http, https를 구분하지 않고 전송
• Secure를 적용하면 https인 경우에만 전송

 

HttpOnly

 

• XSS 공격 방지
• 자바스크립트에서 접근 불가(document.cookie)
• HTTP 전송에만 사용

 

SameSite

 

• XSRF 공격 방지
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송