본문으로 바로가기
반응형

 

 

 

 

 

● HTTP 헤더

 

 

 

HTTP 헤더 필드는 아래와 같이 구성되어 있다.

 

 

header-field = field-name ":" field-value

ex) Content-Type: text/html;charset=UTF-8

     Content-Length: 3423

 

 

 

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 포함한다.

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

 

 

 

 


● 과거 HTTP 헤더 분류

 

 

 

과거에는 헤더를 4가지로 분류했다.

 

 

 

 

• General 헤더: 메시지 전체에 적용되는 정보,

예) Connection: close

 

• Request 헤더: 요청 정보

예) User-Agent: Mozilla/5.0 (Macintosh; ..)

 

• Response 헤더: 응답 정보

예) Server: Apache

 

• Entity 헤더: 엔티티 바디 정보

예) Content-Type: text/html, Content-Length: 3423

 

 

 

 

 

 

● 과거 HTTP BODY

 

 

 

메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는 데 사용되었다.

 

엔티티 본문은 요청이나 응답에서 전달할 실제 데이터를 담았다. 

엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공했다.

EX) 데이터 유형(html, json), 데이터 길이 등등

 

 

 

 

 

 

● 최신 HTTP BODY

 

 

 

최신 HTTP BODT는 메시지 본문(message body)을 통해 표현 데이터를 전달한다.

그리고 메시지 본문을 페이로드(payload)라는 용어로 변경하였다.

 

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

표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.

 

 

 

 

 

 


● 표현 

 

 

 

HTTP 표현은 4가지로 분류된다.

 

 

• Content-Type: 표현 데이터의 형식

  - 미디어 타입, 문자 인코딩

  - ex) text/html; charset=utf-8, application/json

 

 

• Content-Encoding: 표현 데이터의 압축 방식

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

  - 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가

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

  - ex) gzip

 

 

• Content-Language: 표현 데이터의 자연 언어

  - 표현 데이터의 자연 언어를 표현

  - ex) ko, en, en-US

 

 

• Content-Length: 표현 데이터의 길이

  - 바이트 단위

 

 

 

 

 


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

 

 

 

협상이란 클라이언트가 선호하는 표현 요청을 말한다.

 

클라이언트가 서버에게 이렇게이렇게 전달해주세요~ 하는 것이다.

 

 

협상은 4가지로 분류된다.

 

 

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

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

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

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

 

 

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

 

 

 

 

 

 


● 전송 방식

 

 

 

전송 방식은 4가지로 분류된다

 

 

• 단순 전송

  - 서버가 Content-Length의 길이를 지정해주고 그대로 클라이언트에게 전달

 

• 압축 전송

  - 서버가 Content-Encoding을 사용하여 어떤 형태로 압축되었는지 클라이언트에게 전달

 

• 분할 전송

  - 서버가 전송해야할 데이터가 클 때 Transfer-Encoding을 사용하여 분할로 보낼 수 있음

 

• 범위 전송

  - 서버가 Content-Range를 사용하여 지정된 범위만큼 데이터를 전송

 

 

 

 

 

 


● 일반 정보

 

 

 

• From: 유저 에이전트의 이메일 정보

  - 검색 엔진 같은 곳에서, 주로 사용

 

 

• Referer: 이전 웹 페이지 주소

  - 현재 요청된 페이지의 이전 웹 페이지 주소

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

 

 

• User-Agent: 유저 에이전트 애플리케이션 정보

  - 클리이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)

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

 

 

• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보

  - 응답을 받기위해 중간에 거치는 server가 아닌 진짜 응답을 보내주는 원 서버

 

 

• Date: 메시지가 생성된 날짜

  - Date: Tue, 15 Nov 1994 08:12:31 GMT 이런 형식으로 지원된다.

 

 

 

 

 

 


● 특별한 정보

 

 

 

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

  - 하나의 서버가 여러 도메인을 처리해야 할 때 사용된다.

 

 

• Location: 페이지 리다이렉션

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

 

 

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

  - ex) PUT, DELETE 요청만 가능한 서버에 POST로 요청 시 서버가 Allow를 통해 알려줌

 

 

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

  - 503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음

 

 

 

 

 

 


● 쿠키

 

 

 

쿠키를 사용할 떄 다음 2가지 헤더가 사용된다.

 

 

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

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

 

 

 

쿠키가 필요한 이유는 HTTP가 무상태(Stateless) 프로토콜이기 때문이다.

 

클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.

클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다. 

클라이언트와 서버는 서로 상태를 유지하지 않는다

 

 

 

서버에서 쿠키를 생성할 때 아래와 같은 구조로 생성한다.

 

set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT;

path=/; domain=.google.com; Secure

 

 

 

○ 쿠키 - 생명주기

 

 

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

  - 만료일이 되면 쿠키 삭제

 

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

  - 0이나 음수를 지정하면 쿠키 삭제

 

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

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

 

 

 

 

 

○ 쿠키 - 도메인

 

예) domain=example.org

 

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

  • domain=example.org를 지정해서 쿠키 생성

     - example.org, dev.example.org도 쿠키 접근

 

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

  • example.org 에서 쿠키를 생성하고 domain 지정을 생략

     • example.org 에서만 쿠키 접근, dev.example.org는 쿠키 미접근

 

 

 

 

 

 

○ 쿠키 - 경로

 

 

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

• 일반적으로 path=/ 루트로 지정

 

ex) • path=/home 지정

       - /home -> 가능

       - /home/level1 -> 가능

       - /hello -> 불가능

 

 

 

 

 

 

○ 쿠키 - 보안

 

 

 

• Secure

  - 쿠키는 http, https를 구분하지 않고 전송

  - Secure를 적용하면 https인 경우에만 전송

 

 

• HttpOnly

  - XSS 공격 방지

  - 자바스크립트에서 접근 불가(document.cookie)

  - HTTP 전송에만 사용

 

 

• SameSite

  - XSRF 공격 방지

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

 

 

 

 

 


 

 

 

다음 포스팅에선 캐시와 조건부 요청에 대해서 다뤄보고자 한다.

https://healthdevelop.tistory.com/entry/http13

 

[HTTP] HTTP 헤더(캐시와 조건부 요청) | 콘텐츠 협상 | 표현 | 인증 | 쿠키 | 캐시 | 조건부 요청 | 검

지난 포스팅에 이어 HTTP 헤더에 대해 더 깊이 알아보고자 한다. https://healthdevelop.tistory.com/entry/http12 [HTTP] HTTP 헤더(일반 헤더) | 콘텐츠 협상 | 표현 | 인증 | 쿠키 | 캐시 | 조건부 요청 | 검증..

healthdevelop.tistory.com

 

반응형