섹션 7. HTTP 헤더1 - 일반 헤더

헤더는 크게 일반 헤더와 캐시/조건부 헤더 2가지로 나뉜다.

 

1. HTTP 헤더 용도

-> HTTP 전송에 필요한 모든 부가 정보 포함

-> ex) 메시지 바디의 내용 및 크기, 압축, 인증, 요청 클라이언트, 서버 등

 

2. 표준 헤더도 너무 많이 존재

 

 

3. 과거 HTTP 헤더 (RFC2616)

-> 과거엔 header를 크게 4가지로 분류  

• General header: 메시지 전체에 적용되는 정보
• Request header: 요청 정보
• Response header: 응답 정보
• Entity header: 엔티티 바디 정보 ex) Content-type: text/html, Content-Lenght: 3423

-> 메시지 본문은 엔티티 본문을 전달하는데 사용

-> 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공 ( data type : html, json, data length etc)

 

4. 현재 HTTP 헤더의 변화

• 단어의 변화:  Entity -> 표현(Representation)
• Representation = representation MetaData + Representation Data (표현 = 표현 메타데이터 + 표현 데이터)
• 여기서 Representation의 R은 REST의 R과 상통

-> 과거와 바뀐 것은 표현이란 단어 (from entity to representation)

 

 

5. 표현 (표현 헤더는 전송, 응답 둘다 사용)

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

-> Content-Language 경우, 예를 들어, Apple 공홈에서 언어선택을 무엇으로 하느냐에 따라 Content-Language 값이 변경된다.

 

6. Content-Encoding : 표현 데이터 인코딩

-> 표현 데이터를 압축하기 위해 사용

-> 데이터 전달 쪽에서 압축 후 인코딩 헤더 추가

-> 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제

 

ex) gzip(실무에서 본 형식), deflate, identity(압축을 하지 않은 상태, 보낸 데이터와 받는 데이터의 상태가 동일하다는 뜻)

 

 

7. 협상 (content negotiation)

-> 클라이언트가 선호하는 표현을 보내달라고 서버에 요청

-> 즉 협상은 request일 때만 사용된다.

 

8. 협상의 종류

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

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

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

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

 

9. 협상과 우선순위

-> Quality Values(q) 값 사용

-> 값이 범위는 0~1로, 클수록 높은 우선순위 갖는다. -> 생략하면 1

-> ko-KR;q=1 (생략)

-> 숫자 높은대로 우선순위 갖는다( ko-KR -> en-US )

-> 이렇게 설계하면, 서버가 독일어(우선)와 영어밖에 지원하지 않을 때, 클라이언트가 요청한 협상 우선순위 내용에 따라 content-language를 영어로 설정하여 응답한다.

-> 이러한 서버에, 우선순위 없이 ko-KR만 요청할 경우, 요청받은 랭귀지를 지원하지 않기 때문에 곧바로 독일어로 응답할 수 있다.

-> 그러니 우선순위를 설정해서 요청하는 것!

 

 

10. 협상과 우선순위: 구체적인 것이 우선

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

 

- 클라이언트가 위와 같은 미디어 타입을 요청할 때

1. text/plain;format=flowed (가장 구체적이므로 높은 우선순위 갖는다)
2. text/plain
3. text/* 
4. */* 

 

11. HTTP의 전송 방식

• 단순 전송: content-length
• 압축 전송: content-encoding
• 분할 전송
• 범위 전송

12. 단순 전송과 압축 전송

응답 메시지 헤더에 단순 전송과 압축 전송에 대한 정보 표시

 

13. 분할 전송

-> 용량 큰 데이터를 쪼개서 보내는데, 이때는 content-length를 보내지 않는다(쪼개서 보내기에)

 

14. 헤더의 일반 정보

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

15. From

-> 유저 에이전트의 이메일 정보 (일반적으로 많이 사용되지 않음)

-> 요청시, 검색엔진 같은 곳에서 주로 사용

 

16. Referer (referer는 referrer의 오타 -> 여담: 처음에 잘못 세팅되어 현재는 그냥 사용하는 상황 )

-> 구글에서 hello를 검색하여 어느 웹사이트로 이동힐 때, 검색과정에서 가장 마지막으로 거친 이전의 웹 페이지 주소를 나타낸다.

-> Referer를 사용해서 유입 경로 분석 가능

 

17. User-Agent

-> 사용자 본인의 웹브라우저의 정보 ( 요청에서 사용 ) 

-> 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능

 

18. Server

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

-> Http 요청을 보내면 수많은 proxy 서버를 거쳐 최종적으로 origin 서버에 닿게 된다.

 

19. Date

-> 메시지가 발생한 날짜와 시간 ( 응답에서 사용 )

 

20. 헤더의 특별한 정보

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

 

21. Host

-> 하나의 서버(or IP)가 여러 도메인을 처리해야 할 경우(아래 그림처럼), 

-> request에서 보낸 Host정보를 읽고 서버에서 hosting을 진행한다.

 

22. Location

-> Page redirection

-> Location값은 요청을 자동으로 redirection하기 위한 대상 리소스를 가리킨다.

 

23. Allow

-> 허용 가능한 HTTP 메서드

-> Allow: GET, HEAD, PUT

 

24. Retry-After

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

-> 503 에러: 서비스가 언제까지 불능인지 알려줄 수 있다. 

 

25. 인증

Authorization: 클라이언트 인증 정보를 서버에 전달

WWW-Authenticate: WWW-Authenticate 응답 헤더는 리소스의 액세스를 얻기 위한 인증 방법을 정의

 

26. 쿠키

-> set-cookie: 서버에서 클라이언트로 쿠키 전달(응답:response)

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

 

27. 쿠키: 모든 요청에 정보를 넘기는 문제

-> 아래처럼 모든 요청마다 state(사용자 정보)를 넣어 요청한다면

-> 문제1) 모든 요청에 사용자 정보가 포함되도록 개발해야함 ( 난이도 up )

-> 문제2) Browser를 완전히 종료하고 다시 열면 저장된 상태가 모두 날라간다.

 

28. 쿠키 저장소

 

29. 쿠키 - 생명주기 <Expires, Max-age>

-> set-cookie: expires = Mon, 31-DEC-2021 12:00:00 GMT -> 만료일 되면 쿠키 삭제

-> set-cookie: max-age = 3600 (3600초)

-> 세션 쿠키: 만료 날짜 생략하면 브라우저 종료시 까지만 유지

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

 

30. 쿠키 - 경로 <Path=/루트로 지정>

-> 해당 경로를 포함한 하위 경로 페이지에서만 쿠키 접근 가능 (하위 경로는 모두 가능!)

 

31. 쿠키 - 보안

-> Secure

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

-> HttpOnly

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

-> SameSite (비교적 최신 기술, 기능이 적용된지 얼마 안됐다.)

• XSRF 공격 방지
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 사용 (SameSite를 설정하지 않으면, 도메인이 같지 않은 경우에도 쿠키가 전송될 수 있기에, SameSite로 이를 방지)