07. HTTP 웹 기본 지식 - HTTP 헤더 개요

일반헤더

HTTP 헤더 개요

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

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

표준 해더가 있지만 너무 많고 필요시 임의의 헤더 추가 가능하다. 예) TOKEN : AEJEONG

 

과거에의 HTTP 헤더 분류

Request 헤더 : 요청 정보 예) User-Agent : Mozila/5.0 (Macintosh; ..) -> 클라이언트가 서버어게 유저의 기기 정보를 알려준다.

Response 헤더 : 응답 정보 예) Server: Apache -> 서버가 클라이언트에게 서버 정보를 알려준다.

General 헤더 : 메시지 전체에 적용되는 정보 예) Connection: close 

Entity 헤더 : 엔티티 바디 정보 예) Content-Type : text/html, Content-Length: 3423

-> HTTP BODY는 Entity 본문을 전달하는데 사용하는데 요청/응답에서 전달할 실제 데이터이다. 여기서 Entity 헤더는 Entity 본문의 데이터를 해석할 수 있는 정보를 제공해준다. 예를들어 데이터 유형(html, json), 데이터 길이, 압축 정보 등등 

 

2014년 이후 스펙이 변경된다

- Entity -> Representation(표현) , 표현 = 표현 메타데이터 + 표현 데이터 즉 실제 전달되는 데이터를 표현이라고 정의하였다.

모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한 / 인프런

- 메시지 본문(body)을 통해 표현 데이터 전달 (페이로드)

- 표현은 요청이나 응답에서 전달할 실제 데이터

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

 

-> HTTP 메시지로 회원의 대한 리소스를 전달한다고 했을 때 헤더에 사용할 수 있는 표현

- Content-Type : 표현 데이터의 형식 설명 - 미디어 타입, 문자 인코딩 예) text/html; charset=utf-8 , application/json

- Content-Encoding : 표현 데이터 인코딩 - 표현 데이터 압축하기 위해 사용, 데이터 전달하는 곳에서 압축 후 인코딩 헤더 추가, 데이터 읽는 쪽에서 압축 해제

- Content-Language : 표현 데이터의 자연 언어 - 표현 데이터의 자연 언어를 표현 예) ko, en, en-US

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

 

 

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

클라이언트가 선호하는 표현 요청

-> 클라이언트가 서버에게 원하는 방식을 요청한다.

- Accept : 클라이언트가 선호하는 미디어 타입 전달

- Accept-Charset : 클라이언트가 선호하는 문자 인코딩

- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩

- Accept-Language : 클라이언트가 선호하는 자연 언어

-> 협상 헤더는 요청시에만 사용

 

클라이언트에서 요청을 보낸다 -> 서버는 영어로된 브라우저를 기본으로 응답한다.

Accept-Language 를 적용하면 클라이언트에서 요청할 때 Accept-Language: ko 를 같이 보내게 되어서 서버에서 클라이언트가 원하는 언어의 리소스를 전달할 수 있다.

 

우선순위를 정할 수도 있다. 기본으로 제공해주는 언어가 독일어 일때 한국 클라이언트는 영어롤 좀더 친숙해한다.

그렇기 때문에 클라이언트에서 우선순위를 정해 주어서 좀더 친숙한 언어로 리소를 응답받을 수 있다.

 

0~1 로 숫자가 높을 수록 우선순위가 크다.

예)

GET /event

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

 

실제 페이지 Network - Headers 살펴보았다.

구체적인 것이 우선한다. 

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

인식 되는 순서 : text/plain;format=flowed -> text/plain -> text/* -> */*

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

 

 

전송 방식

- 단순 전송 : Content-Length 한번에 요청하고 한번에 받는다.

- 압축 전송 : Content-Encoding (gzip) 압축해서 클라이언트에게 응답한다.

- 분할 전송 : Transfer-Encoding : chunked 서버에서 만들어질 응답이 만들어질 때마다 분할되서 클라이언트에게 보낸다. (한번에 보내기엔 커서 시간이 오래걸릴 때 사용하는 분할 전송) - length를 넣으면 안된다, 분할되어 전달되기 때문에 계속 변경.

- 범위 전송 : Reang, Content-Range - 클라이언트에서 범위를 정해서 요청하고 서버는 해당 범위를 전달한다. 

 

 

일반 정보

- From : 유저 에이전트의 이메일 정보, 일반적으로 잘 사용되지 않음, 검색 엔진 같은 곳에서 주로 사용 (요청)

- Referer : 이전 웹 페이지 주소, A->B 로 이동할 때 B를 요청할 때 Refere:A 를 포함하여 요청한다.,유입 경로 분석이 가능하다 (요청)

- User-Agent : 유저 에이전트 애플리케이션 정보, 클라이언트의 애플리케이션 정보 ( 웹 브라우저 정보, 등등), 통계 정보, 어떤 종류의 브라우저에서 장애가 발생한지 파악이 가능하다. (요청)

- Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보 (응답)

ORIGIN 서버란 요청을 보낼 때 중간의 프록시 서버가 아닌 리소스가 있는 서버를 칭한다!

예) Server : Apache/2.2.22 (Debian)

- Date : 메시지가 발생한 날짜와 시간 (응답)

 

특별한 정보

- Host : 요청한 호스트 정보 (도메인) (요청)  * 필수

하나의 서버가 여러 도메인을 처리 할 때

하나의 IP 주소에 여러 도메인이 적용되어 있을 때 

 

하나의 서버에 aaa.com, bbb.com, ccc.com 의 도메인을 호스팅하고 있을 때 IP 만으로 찾아갈수 없기 때문에 Host 필드를 헤더에 필수로 정하였다.

 

- Location : 페이지 리다이렉션

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 이동한다 (리다이렉트)

201 에서는 요청에 의해 생성된 리소스 URI을 Location에 담아서 응답한다.

 

- Allow : 허용 가능한 HTTP 메서드

405에서 응답을 포함해야함 Allow: GET, HEAD, PUT 

서버에서 해당 메서드만을 허용한다고 클라이언트에게 알려주는 용도이다.

 

-Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

503에서 서비스가 언제까지 불능인지 알려줄 수 있다. Retry-Ater : Fri, 31 Dec 1999 23:59:59 GMT (날짜) ,120 (초단위 표기) 등을 사용 

 

 

인증 Header

- Authorization : 클라이언트 인증 정보를 서버에 전달 예) Authorization: Basic xxxxxxxxxxx

- WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의

리소스 접근시 필요한 인증 방법 정의 -> 401 응답에 넣어줘야 한다.

예)

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="MyRealm"

Content-Length: 0

종류가 많다!

realm이 뭐지?

요청받은 문서의 집합을 큰따음표로 감싼것으로 클라이언트가 이것을 보고 어떤 비밀번호를 사용해야하는지 알 수 있게 해준다.

 

쿠키

- Set-Cookie : 서버에서 클라이언트로 쿠키 전달 (응답)

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

 

예 )

쿠키 미사용시

처음 페이지에 접근한다 -> 로그인한다 -> 로그인 이후로 다시 페이지에 접근한다 -> 서버는 손님으로 인식한다.

어떤 사용자가 요청했는지 서버가 구분할 수 없다. 왜? HTTP는 무상태 프로토콜이기 때문에 응답하고 연결이 끊어진다.

이럴 경우 모든 요청에 정보를 넘기는 문제가 생기고, 브라우저를 종료 후 다시 열면 . . .? 

 

쿠키 사용

웹브라우저에서 요청한다 ->  서버에서 해당 유저 정보와 매칭되는 key값을 Set-Cookie : 를 만들어 응답한다.->  클라이언트는 해당 응답을 받아서 쿠키 저장소에 저장한다. -> 클라이언트가 요청할 때 브라우저가 자동으로 쿠키저장소에 있는 key값 을 찾아서 header에 포함한다 -> 서버는 header에 있는 쿠키를 통해 유저를 식별한다.

 

사용처

- 사용자 로그인 세션 관리

- 광고 정보 트래킹

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

- 네트워크 트래픽 추가 유발 (단점)

- 최소한의 정보만 사용(세션 id, 인증 토큰)

- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 참고

  -> 클라이언트에서 웹 스토리지에 보관하고 있다가 필요할 때만 서버에게 준다.

* 보안에 민감한 데이터는 저장하면 안됨!

 

실무에서 쿠키를 활용하는 방법을 몰라 사용 했던 방법

서버에서 token값을 http body에 넣어서 전달한다 -> 클라이언트가 해당 token을 받아서 웹 스토리지에 저장한다.-> 요청할 때 마다 웹 스토리지에 있는 token 값을 꺼내서 요청한다.

 

하지만 쿠키를 사용한다면? 

서버에서 token을 set-Cookie 한다. -> 클라이언트는 쿠키 저장소에 해당 token을 저장한다 -> 클라이언트가 요청을 보낸다 ( 브라우저가 쿠키저장소에 잇는 token을 찾아서 요청을 보내겠지?) 

 

쿠키 - 생명주기

Expires, max-age

- Set-Cookie: expires = Sat, 26-Dec-2020 .... : 만료일이 되면 쿠키 삭제

- Set-Cookie : max-age = 3600(3600초) : 0이나 음수를 지정하면 쿠키 삭제

- 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지 -> 브라우저를 모두 끄면 자동으로 로그아웃되는 것!

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

 

쿠키 - 도메인

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

예) domain=example.org를 지정해서 쿠키 생성 하게 되면 example.org는 물론이고 dev.example.org의 쿠키에도  접근 가능하다.

만약 도메인 지정을 생략한다면 example.org 에서만 쿠키 접근할 수 있다. dev.example.org에서는 불가능

 

쿠키 - 경로

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

일반적으로 path=/ 루트로 지정 -> 일반적으로 전체적으로 쿠키전송을 하기 때문에

 

쿠키 - 보안

- Secure

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

- HttpOnly

XSS 공격 방지, 자바스크립트에서 접근 불가하게 한다. ( document.cookie )

HTTP 전송에만 사용

- SameSite

XSRF 공격 방지

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