7. HTTP 헤더 - 일반헤더

HTTP 헤더

 

• 정의

헤더 필드는 field-name + “:” + OWS + field-value + OWS로 이루어져 있다. (OWS = 띄어쓰기 허용)

field-name에는 대소문자 구분이 없다.

노란칸이 헤더부분이다.

 

• 용도

HTTP 전송에 필요한 모든 부가 정보

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

표준헤더가 너무 많다.

필요시 임의의 헤더를 추가할 수 있다.

 

과거 - RFC2616

1. HTTP 헤더

 

• 헤더 분류

General Header = 메시지 전체에 적용되는 정보ex) Connection: close

Request Header = 요청 정보 ex) User-Agent: Mozilla/5.0 (Macintosh; ..)

Response Header = 응답 정보 ex) Server: Apache

Entity Header = Entity 바디 정보 ex) Content-Type: text/html, Content-Length: 3423

 

2. HTTP 바디

메시지 본문은 Entity 본문을 전달하는데 사용한다.

Entity 본문 - 요청이나 응답에서 전달할 실제 데이터

Entity 헤더 - Entity 본문의 데이터를 해석할 수 있는 정보, 데이터 유형(html, json), 데이터 길이, 압축 정보 등

후에 RFC2616가 폐기되고 2014년에 RC7230~7235가 등장하면서 엔티티 바디는 사라진다.

Entity 대신 표현(표현 메타데이터 + 표현 데이터)이 추가되었다.

 

현재 - RFC7230

HTTP 바디

메시지 본문(message body = payload)을 통해 표현 데이터를 전달한다.

표현 - 요청이나 응답에서 전달할 실제 데이터, 표현 = 표현헤더 + 표현데이터

표현 헤더 - 표현 데이터를 해석할 수 있는 정보, 데이터 유형(html, json), 데이터 길이, 압축 정보

 

ex) 회원이라는 리소스를 json이라는 표현으로 전달한다.

 

표현

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

• Content-Type - 표현 데이터의 형식으로 html인지 json인지 등을 알려준다.
• Content-Encoding - 표현 데이터의 압축 방식
• Content-Language - 표현 데이터의 자연 언어
• Content-Length - 표현 데이터의 길이 정확히는 payload 헤더에 해당한다.

 

1. Content-Type

바디에 들어가는게 뭐야?

미디어 타입, 문자 인코딩 등 표현 데이터의 형식으로 바디에 어떤 데이터가 들어가는지 설명한다.

ex)

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

 

2. Content-Encoding

표현 데이터를 압축할 때 사용한다. 데이터를 전달하는 곳에서 메시지 바디를 압축하고 그 정보를 인코딩 헤더에 추가해서 보낸다. 데이터를 읽는 쪽에서 이 정보를 가지고 압축을 해제한다.

ex)

• gzip
• deflate
• identity

 

3. Content-Language

아 한국어를 쓰는구나~, 아 영어를 쓰는구나~

표현 데이터의 자연언어를 표현한다.

ex)

• ko
• en
• en-US

 

4. Content-Length

표현 데이터의 길이를 바이트 단위로 나타내며, Transfer-Encoding(전송 코딩)사용시 전송 코딩 안에 정보가 다 들어있어 사용하면 안된다.

---

콘텐츠 협상

클라이언트가 선호하는 표현을 서버에 요청하는 것으로, 원하는 대로 서버는 표현 데이터를 만들면 된다.

협상 헤더는 요청시만 사용한다.

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

 

1. Accept-Language를 적용하기 전에는 기본값인 영어로 응답을 한다.

언어 정보가 없으므로 기본값인 영어로 반환해준다.

2. 적용하면 선호하는 언어를 확인하고 있으면 그 언어로 보내준다.

Accept-Language를 정해줬으므로 한국어로 반환해준다.

3. 하지만 만약 기본이 독일어 이고 영어를 지원하는 곳이면 한국어가 안되더라도 영어가 아닌 독일어로 나온다.

 

---

협상과 우선순위1

따라서 우선 순위를 정할 수 있다. q값에 0~1 사이의 우선 순위를 부여한다. 클 수록 우선순위가 높으며 생략하면 1이다.

ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

생략되었으므로 한국인이 쓰는 한국어 ko=1로 우선순위가 가장 높다. 그 다음 일반 한국어, 미국영어,공통 영어 순이다.

우선 순위를 주면 한국어 다음으로 영어를 원한다는 것을 서버가 파악하고 영어로 보내준다.

 

협상과 우선순위2

내용은 구체적인 것을 우선한다.

• Accept: text/, text/plain, text/plain;format=flowed, /

1순위: text/plain;format=flowed

2순위: text/plain

3순위: text/*

4순위: /

 

---

전송 방식

1. 단순 전송(Content-Length) - 요청을 하면 미리 컨텐츠의 길이를 알고 지정해서 보내는 방식이다.

 

2. 압축 전송(Content-Encoding) - 서버에서 압축 해서 용량을 줄인 후 Content-Encoding에 뭘로 압축했는지 정보를 같이 보낸다. 그래야 클라이언트에서 알고 풀 수 있다.

 

3. 분할 전송(Transfer-Encoding) - 덩어리로 쪼개서 보낸다는 의미로 chunked 값을 주는 방식이다.

“5Byte를 먼저 보내고 이 값이 Hello”이고, 끝나면 0 \r\n 을 보낸다.

한 번에 쭉 보내려면 대기 시간이 필요한데 이렇게 쪼개면 만들어지는 대로 바로바로 응답을 받을 수 있는 장점이 있다. 참고로 이 방식은 Content-Length를 사용할 수 없다. 쪼개서 보내므로 길이를 예상할 수 없기 때문이다.

 

4. 범위 전송(Range, Content-range) - 절반 정도 받고 끊겼는데 처음부터 다시 요청하기엔 아까우니 범위를 지정해서 요청하는 방식이다.

 

 

---

헤더에 포함되는 정보

1. 일반 정보

 

• From

유저 에이전트의 이메일 정보, 잘 사용되지 않음. 요청에서 사용하는 정보로 검색 엔진 등에서 주로 사용한다.

 

• Referer

이전 웹 페이지 주소를 알려준다.

현재 요청된 페이지의 이전 웹 페이지 주소, 요청에서 사용하는 정보로 자주 사용한다.

A에서 B로 이동하는 경우, B 요청 시 Referer: A를 포함해서 요청한다.

Referer 정보로 유입 경로를 분석할 수 있다.

 

• User-Agent

클라이언트의 애플리케이션 정보( ex)웹 브라우저 정보), 요청에서 사용하는 정보로 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능하며, 사용자 통계 정보를 보기 좋다.

 

• Server

요청을 처리하는 origin 서버의 소프트웨어 정보로 실제 응답을 해주는 진짜 서버를 origin이라고 한다.

중간에 있는 거 다 빼고 나의 요청이 있는 마지막 서버

응답에서 사용하는 정보이다.

 

• Date

메시지가 발생한 날짜정보,응답에서 사용하는 정보이다.

 

2. 특별한 정보

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

요청에서 사용하는 정보이며 필수 값이다.

하나의 서버가 여러 도메인을 처리해야 할 때. 즉, 한 IP에 여러 도메인이 적용된 경우 사용한다.

예를 들어, 가상 호스트로 여러 도메인을 한번에 처리하는 서버가 있어서 애플리케이션이 여러 개 구동되고 있을 수

있다.

host가 없으면 서버는 /hello가 어떤 애플리케이션에 해당되는지 알 수 없다. 통신은 IP로만 하기 때문에

host를 담아 전송하면 서버는 적절한 곳으로 보낸다.

포트랑 비슷한가?

호스트: IP에 이름을 부여한 도메인 네임이나 서버컴퓨터 IP

포트: 한 컴퓨터에서 어느 서버 프로그램과 통신할 것인지 지정해주는 출입구

 

• Location

페이지 리다이렉션에 쓰인다.

웹 브라우저가 3xx 응답 결과에 Location이 있으면 그 위치로 자동 이동한다.

201 (Created)일 땐 요청에 의해 생성된 리소스 URI 값이 들어온다.

3xx (Redirection)일 땐 요청을 자동으로 리다이렉션 하기 위한 대상 리소스를 가리킨다.

 

• Allow

허용 가능한 HTTP 메서드를 나타낸다.

405 (Method Not Allowed)일 땐 응답에 포함해야 한다.

 

• Retry-After

유저 에이전트가 다음 요청을 하기전까지 기다려야 하는 시간으로

503 (Service Unavailable)일 때 서비스가 언제까지 불능인지 알려줄 수 있다.

---

인증

• Authorization

클라이언트 인증 정보를 서버에 전달한다. 들어가는 값은 인증 방식마다 다르다.

Authorization 헤더는 클라이언트가 서버에게 자신을 인증하는 데 사용

• WWW-Authenticate

리소스에 접근할 때 필요한 인증 방법을 정의한다.

401 Unauthorized응답에 함께 사용한다. 401오류시 아래와같은 헤더를 넣어준다.

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

WWW-Authenticate 헤더는 서버가 클라이언트에게 어떤 인증 방법을 사용해야 하는지 알려주는 데 사용

 

정리하자면

Authorization는 클라이언트가 서버로 요청을 보낼 때, 자격 증명을 서버에 전달하는 데 사용되며,주로 HTTP 요청에서 인증 정보를 포함하는 데에 활용된다.

WWW-Authenticate는 서버가 클라이언트에게 보낸 응답에서, 클라이언트에게 어떤 인증 방법을 사용해야 하는지 알려주는 데에 사용되고, 클라이언트는 이 정보를 기반으로 인증 헤더를 생성하여 다시 서버로 전송한다.

 

---

쿠키

웹 브라우저에서 어떤 서버에 처음 접근을 했다고 해보자.

로그인을 하면 서버는 로그인을 했다고 응답을 준다.

로그인 후 다시 /welcome 페이지에 접근을 하면 서버는 처음 접근한 것과 같은 응답을 준다.

/welcome에 접근한다는 것 말고는 어떤 정보도 없기 때문에 서버는 누가 로그인을 했는지 알 수 없다.

HTTP는 무상태 프로토콜이기에, 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊긴다.

서로 상태를 유지하지 않기 때문에 클라이언트가 다시 요청해도 서버는 이전 요청을 기억하지 못한다.

대안으로 모든 요청에 사용자 정보를 포함해서 보낼 수 있다.

하지만 이 대안은 모든 요청과 링크에 사용자 정보를 포함하기 때문에 보안 문제도 생기고 개발이 복잡해진다.

또한, 브라우저를 완전히 종료하고 다시 열면 또 다시보내야 한다.

 

그래서 쿠키가 도입되었다.

브라우저가 로그인을 하면 서버가 Set-Cookie 헤더에 정보를 넣어 반환한다.

그러면 웹 브라우저 내부에 있는 쿠키 저장소에 Set-Cookie 값을 저장한다.

로그인 이후에 다시 페이지에 접근하면 무조건 쿠키 저장소에서 조회해서 Cookie에 유저 값을 넣어 보낸다.

지저분하게 URL에 넣을 필요가 없어지는 것이다.

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

set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure**

 

쿠키 사용처

• 사용자 로그인 세션 관리

유저 정보를 그대로 보내면 위험하기 때문에 세션 키를 서버에서 만들어서 DB에 저장해두고 sessionId 값으로 보낸다. 클라이언트는 그 sessionId를 저장해두고 요청할 때마다 보낸다.

• 광고 정보 트래킹

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

 

단점

쿠키 정보는 항상 서버에 전송되므로 네트워크 트래픽을 유발한다.

그래서 세션 ID와 인증 토큰 정도의 최소한의 정보만 사용해야 한다.

주민 번호와 신용카드 번호 등 보안에 민감한 데이터는 저장하면 안된다.

서버에 전송하지 않고 클라이언트 즉, 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지를 사용한다.

 

생명 주기(expires, max-age)

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

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

 

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

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

 

• 세션 쿠키

만료 날짜를 생략하면 브라우저를 종료할 때까지만 유지한다.

 

• 영속 쿠키

만료 날짜를 입력하면 해당 날짜까지 유지한다.

 

domain

쿠키가 사용되는 도메인을 명시할 수 있다.

ex) domain = example.org

 

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

example.org는 물론이고 dev.example.org의 형태에도 쿠키로 접근한다.

 

• 생략: 현재 문서 기준의 도메인만 적용한다.

example.org에서만 쿠키로 접근한다. dev.example.org는 쿠키로 접근할 수 없다.

 

path

path=/home

해당 경로를 포함한 하위 경로 페이지만 쿠키로 접근한다.

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

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

 

보안

• Secure

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

• HttpOnly

XSS 공격을 방지한다. 자바스크립트에서 원래 쿠키를 접근할 수 있는데(document.cookie) 이 옵션이 들어가면 불가능하다. HTTP를 통해서만 쿠키를 사용하게 된다.

• SameSite

XSRF 공격을 방지한다. 요청한 도메인과 쿠키에 설정된 도메인이 같을 때만 쿠키를 전송하는 것이다. 다른 사이트에서 세팅한 쿠키를 전송되지 않게 한다.