HTTP 헤더란?
용도
- HTTP 전송에 필요한 모든 부가 정보
- 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등
Content-Type: text/html;charset=UTF-8
Content-Length: 1212
과거와 현재
Header의 구분 방식
- 1999년 - RFC2616
General 헤더
,Request 헤더
,Response 헤더
,Entity 헤더
로 구분되었음
- 2014년 - RFC7230~7235 등장
- 엔티티(Entity) 헤더 → 표현(Representatition) 헤더 + 표현 데이터
- 메시지 본문을 통해서 표현 데이터 전달
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>
- 표현 헤더 :
Content-Type
,Content-Length
- 표현 데이터 : html 부분
- 표현 데이터는 요청 또는 응답에서 실제로 전달하는 데이터
- 표현 헤더는 표현 데이터를 해석할 정보를 제공한다.
표현(Representation) 헤더
표현 헤더는 전송, 응답 둘 다 사용한다.
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>
Content-Type
: 표현 데이터의 형식- 미디어 타입, 문자 인코딩
- 예시 :
text/html; charset=utf-8
,application/json
,image/png
Content-Encoding
: 표현 데이터의 압축 방식- 표현 데이터를 압축하기 위해 사용
- 데이터를 전하는 곳에서 압축 후 인코딩 헤더 추가
- 데이터를 읽는 곳에서 인코딩 헤더의 정보로 압축 해제
- 예시 :
gzip
,deflate
,identity
(압축하지 않음)
Content-Language
: 표현 데이터의 자연 언어- 예시 :
ko
,en
,en-US
- 예시 :
Content-Length
: 표현 데이터의 길이- 바이트 단위
- Transfer-Encoding을 사용하면 Content-Length를 사용하면 안됨
협상 헤더(Contents Negotiation)
클라이언트가 선호하는 표현 요청이다.
클라이언트가 원하는 표현으로 서버에게 요청하면, 해당 우선순위에 맞춰서 서버가 제공
예를 들어서 한국어 브라우저로 여러 언어를 지원하는 사이트에 요청했을때, 클라이언트가 선호하는 언어(Accept-Langauge: ko-KR
)가 추가되어서 서버는 이 헤더를 보고 한국어 페이지를 제공한다.
- Accept : 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset: 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
- Accept-Language: 클라이언트가 선호하는 언어
협상 헤더는 요청시에만 사용
우선순위 지정 - Quality Value
- 컨텐츠 협상에서는 선호하는 표현 형식에 대한 우선순위를 지정할 수 있다.
- 우선순위 지정에는 Quality Values(q) 값을 사용
GET /event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
위의 예시에서 Ko-KR 의 경우 값을 생략 → 1의 값(가장 높은 우선순위)
ko-KR
ko;q=0.9
en-US;q=0.8
en;q=0.7
우선순위 지정 - 더 구체적인 순서대로
- 텍스트의 경우 더 구체적인 것이 가장 높은 우선순위를 가진다.
GET /event
Accept: text/*, text/plain, text/plain;format=flowed, */*
위의 예시에서 text/plain;format=flowed
가 가장 구체적으로 명시 했으므로 가장 높은 우선순위를 가진다.
text/plain;format=flowed
text/plain
text/*
*/*
헤더 전송 방식
전송 방식은 크게 4가지 방식으로 나뉜다.
단순 전송
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>
- 한번에 요청하고, 데이터를 한번에 받는것
압축 전송
Content-Encoding
을 사용
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521
lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjkl
분할 전송
Transfer-Encoding
을 사용- chunk 단위로 데이터를 쪼개서 전송한다.
- 쪼개진 응답이 오는대로 표현할수 있는 장점이 있지만, 데이터의 length를 파악하기 어려워서
Content-Length
를 사용할 수 없다.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5
Hello
5
World
0
\r\n
범위 전송
Content-Range
사용- 데이터의 정해진 범위를 요청해서 받을 수 있다.
- 중간에 요청이 끊겼을 때, 데이터를 받을 범위를 알 수 있는 경우 사용한다.
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Range: bytes 1001-2000 / 2000
qweqwe1l2iu3019u2oehj1987askjh3q98y
일반 정보 헤더
From
- 유저 에이전트의 이메일 정보
- 검색 엔진 같은 곳에서 주로 사용하나, 일반적으로 잘 사용되지 않음
Referer
- 현재 요청된 페이지의 이접 웹 페이지 주소
- A페이지 → B페이지로 이동하는 경우 Referer: A 를 포함해서 요청한다.
- 유입 경로를 분석할때 많이 사용한다.
- 단어 referrer의 오타이다.
User-Agent
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
- 유저 에이전트의 애플리케이션 정보
- 어떤 종류의 브라우저인지, 사용하는 OS 종류 등
- 사용자의 통계 정보를 파악하는데 사용할 수 있다.
- 요청에서 사용
Server
- 요청을 처리하는 origin 서버의 소프트웨어 정보
Server: Apache/2.2.22 (Debian)
- 응답에서 사용
Date
- 메시지가 발생한 날짜 및 시간
Date: Tue, 15 Nov 1994 08:12:31 GMT
- 응답에서 사용
특별 정보 헤더
Host
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
- 하나의 서버가 여러 도메인을 처리해야 할 때
- 하나의 IP주소에 여러 도메인이 적용되어 있을 때
- 필수값이다 → 굉장히 중요!
- 가상 호스트로 하나의 서버에서 여러 도메인을 한번에 처리해서 여러 개의 어플리케이션을 구동 한다.
- IP가 200.200.200.2 인 서버에서
aaa.com
,bbb.com
,ccc.com
3개의 도메인을 처리하는 경우 Host 정보가 없는 경우 클라이언트가 IP로만 요청하면 어떤 도메인으로 가야할 지 모르기 때문에 Host값이 필수로 들어간다.
- 요청에서 사용
Location
- 페이지 리다이렉션
- 웹 브라우저는 300대 응답 결과에 Location 헤더가 있는경우, Location 위치로 자동 이동한다.
Allow
- 허용 가능한 HTTP 메서드
- 405 (Method Not Allowed) 에서 응답에 포함하는 헤더이다.
Allow: GET, HEAD, PUT
Retry-After
- 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- 503 (Service Unavailable): 서비스가 언제까지 이용 불가인지 알려 줄 수 있다
Retry-After: Sun, 20 Jun 2021 02:44:31 GMT
(날짜 표기)Retry-After: 3600
(초 단위 표시)
인증 헤더
Authoriztion
- 클라이언트 인증 정보를 서버에 전달
Authorization: Basic xxxxxxx
WWW-Authenticate
- 리소스 접근시 필요한 인증 방법을 정의
- 401 Unauthorized 응답과 함께 사용
WWW-Authenticate: Newauth realm="apps", type=1, title="Login to apps", Basic realm="simple"
쿠키
HTTP는 무상태(Stateless) 프로토콜이다. 클라이언트와 서버는 서로 상태를 유지하지 않으므로, 클라이언트가 로그인을 해도 서버는 로그인한 상태인지 아닌지 알 수 없다.
이에 따라서, 만약 쿠키와 같은 수단을 사용하지 않을시 모든 요청에 사용자 정보를 포함하도록 개발을 해야한다.
웹 브라우저에는 쿠키 저장소가 존재하는데, 로그인을 할때, 서버에서 쿠키를 넘겨줘서 쿠키저장소에 저장을 하게 된다.
이후에, 쿠키는 모든 요청에 쿠키정보가 자동으로 포함되게 된다.
쿠키의 특성
- 사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹
- 쿠키의 정보는 항상 서버에 전송된다.
- 네트워크 트래픽을 추가 유발함
- 최소한의 정보만 사용(세션 ID, 인증 토큰)
- 서버에 전송하지 않고, 웹브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 사용
- 보안에 민감한 데이터는 저장하면 안된다
- 주민번호, 신용카드 번호 등
쿠키 사용 예시 및 속성
set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
생명주기 속성
expires=Sat
: 만료일(토요일)이 되면 쿠키 삭제max-age=3600
: 3600초 동안 저장, 0이나 음수를 지정하면 쿠키삭제- 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
- 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지
도메인 속성
domain=example.org
- 명시한 경우 : 명시한 문서 기준 도메인 + 서브 도메인 포함
domain=example.org
의 경우, example.org와 dev.exmple.org도 쿠키에 접근
- 생략한 경우 : 현재 문서 기준 도메인만 적용
- example.org에서 쿠키를 생성해 domain 지정을 생략했다면, dev.example.org에서는 쿠키에 접근할 수 없다
경로(Path) 속성
path=/home
- 경로를 포함한 하위 경로 페이지만 쿠키에 접근할 수 있다.
- /home 접근 가능
- /home/test1 접근 가능
- /test1 접근 불가
보안 속성
Secure
- 쿠키는 기본적으로 http, https를 구분하지 않고 전송
- Secure 적용시 https인 경우에만 전송한다.
HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가
- HTTP 전송에만 사용
SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송
Reference
https://www.inflearn.com/course/http-웹-네트워크/dashboard
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com