HTTP 헤더 [협상/전송/쿠키]

Network

HTTP 헤더 [협상/전송/쿠키]

DAHLIA CHOI 2021. 7. 24. 18:52

👉 HTTP 헤더의 용도

HTTP 전송에 필요한 모든 부가정보
필요시 임의의 헤더를 추가할 수 있다.
Ex) 메시지 바디의 내용, 메시지 바대의 크기, 압축, 인증, 서버 정보 등등이 포함되어있다.

👉 HTTP의 표현 형식

field-name":" OWS field-value OWS (OWS는 띄어쓰기 허용이라는 뜻)

👉 과거의 HTTP 헤더 (RFC2616)

General 헤더 : 메시지 전체에 적용되는 정보 ( ex) Connectiond : close )
Request 헤더 : 요청 정보 ( ex) User-Agent: Mozilla/5.0 (Macintosh;... )
Response 헤더 : 응답 정보 ( ex) Server: Apache )
Entity 헤더 : 엔티티 바디 정보 ( ex) Content-Type: text/html, Content-Length: 3423 )

👉 과거 HTTP 바디 (RFC2616)

메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는 데 사용
엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다. ( 데이터 유형(html, json), 데이터 길이...)

👉 현대의 HTTP (RFC7230)

표현 = 표현 헤더 + 표현 데이터

메시지 본문(body)을 통해 표현 데이터 전달
메시지 본문 = 페이로드 (payload)
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공 (데이터 유형 (json, html), 데이터 길이...)

⭐ 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 됨

✍ 표현

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

표현 헤더는 전송, 응답에 둘 다 사용한다.

[ Content-Type ]

미디어 타입, 문자 인코딩

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16

{"data":"hello"}

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 3423

<html>
<body>..</body>
</html>

text/html; charset=UTF-8
application/json ( json은 UTF-8이 기본으로 적용되어있다. )
image/png

[ Content-Encoding ]

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521

lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjkl

표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
gzip, deflate, identity

[ Content-Language ]

Content-Language: ko

표현 데이터의 자연 언어를 표현
ko, en, en-US ...

[ Content-Length ]

Content-Length: 5

바이트 단위
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안 된다.

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

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

이렇게 Accept-Language를 적용하지 않으면 서버에서 가장 우선순위가 높은 언어를 제공한다.

따라서 내가 ko를 원한다면 Accept-Language를 작성해서 보내야 한다.

이렇게 Accept-Language: ko를 작성해서 보내면 한국어로 적용이 된다.

하지만 한국어를 지원하지 않는 서버가 있는데, 내가 한국어가 지원되는지 안되는지 모를 경우에는 우선순위를 지정해서 작성해야 한다. 우선순위를 작성해주지 않는다면,

이렇게 서버에서 가장 우선순위가 높은 언어를 반환한다. 이럴 경우에 우리가 한국어 지원이 안되면, 영어로 나타나게 하려면 언어 사이에 우선순위를 정해줘야 한다.

👇

[ 협상과 우선순위 1 ]

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

Quality Values(q) 값 사용
0~1, 클수록 높은 우선순위이다.
생략하면 1

⭐ 위의 네모칸처럼 작성해서 보내면, 독일어가 아닌 영어를 지원하게 된다.

[ 협상과 우선순위2 ]

구체적인 것이 우선이다.

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

text/plain;format=flowed
text/plain
text/*
*/*

[ 협상과 우선순위 3 ]

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

👉 전송 방식

단순 전송
압축 전송
분할 전송
범위 전송

[ 단순 전송 ]

한 번에 모두 요청하고, 한번에 쭉 받을 수 있는 방법이다.

[ 압축 전송 ]

⭐ 압축 전송을 하려면 무조건 Content-Encoding: gzip을 추가해줘야 한다.

[ 분할 전송 ]

분할로 쪼개서 보내고 싶을 때는 Transfet-Encoding: chunked를 작성해야 한다.
여기서 Content-Length를 사용하면 절대 안 된다.

[ 범위 전송 ]

2000바이트 중에서 절반부터 나머지의 정보를 보내달라는 뜻이다.

👉 일반 정보

From : 유저 에이전트의 이메일 정보
Referer : 이전 웹페이지 주소
User-Agent: 유저 에이전트 애플리케이션 정보
Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보
Date : 메시지가 생성된 날짜

[ From ]

일반적으로 잘 사용하지 않는다.
검색 엔진 같은 곳에서 주로 사용한다.
요청에서 사용한다.

[ Referer ] ⭐

현재 요청된 페이지의 이전 웹 페이지 주소
A -> B로 이동하는 경우, B를 요청할 때 Referer: A를 포함해서 요청한다.
Referer를 사용해서 유입경로 분석 가능
요청에서 사용한다.

구글 화면에서 무엇을 검색하고 나서 헤더 정보를 확인해보면 저렇게 referer가 구글 주소로 되어있는 것을 볼 수 있다.

[ User-Agent ]

클라이언트의 애플리케이션 정보 (웹 브라우저 정보 등등)
통계 정보
어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용

[ Server ]

Server: Apache/2.2.22(Debian)
server: nginx
응답에서 사용한다.

[ Date ]

Date: Tue, 15 Nov 1994 08:12:31 GMT (GMT 기준으로 작성되어있다.)
응답에서 사용한다.

👉 특별한 정보

Host : 요청한 호스트 정보(도메인)
Location : 페이지 리다이렉션
Allow : 허용 가능한 HTTP 메서드
Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

[ Host ]

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

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

[ Location ]

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

[ Allow ]

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 (초단위 표기)

🍪 쿠키 🍪

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

[ 쿠키 미사용 했을 때 ]

HTTP는 무상태(stateless)프로토콜이다.
따라서 클라이언트와 서버가 요청과 응답을 한번 주고받으면 연결이 끊어진다.
그래서 로그인을 하고 나서도 그 전 로그인을 했던 요청에 대한 정보를 기억하지 못한다.
무상태로 설계하면서 정보가 유지되게 하려면 모든 요청에 사용자 정보를 넘겨야 하는데,
이건 너무 복잡하다.
그래서 쿠키를 사용하게 된다.

[ 쿠키를 사용했을 때 ]

⭐ 쿠키는 항상 서버에 전송되기 때문에 보안에 민감한 데이터는 저장하면 안 된다.

[ 생명 주기 ]

Set-Cookie: expire=Sat, 26-Dec-2020 04:39:21 GMT (만료되면 쿠키가 삭제된다)
Set-Cookie: max-age=3600 (3600초를 의미한다. 0이나 음수를 지정하면 쿠키가 삭제된다)
세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시까지만 유지한다.
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지한다.

[ 도메인 ]

domain=example.org

명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
생략 : 현재 문서 기준 도메인만 적용

[ 경로 ]

path=/home

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

[ 보안 ]

◾ Secure

쿠키는 http, https를 구분하지 않고 전송한다.
Secure을 적용하면 https인 경우에만 전송한다. (https가 http보다 보안이 더 높기 때문이다.)

◾ HttpOnly

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

◾ SameSite

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

주소에 항상 들어가는 HTTP가 익숙하긴 했지만 개념을 잡은 건 처음이었다. 직접 페이지의 F12를 클릭해 위의 정보를 하나씩 다 확인하고 나니까 너무 신기했다😃

이 글은 인프런 김영한님의 모든 개발자를 위한 HTTP기본지식을 듣고 작성된 복습 겸 정리 포스팅입니다.