HTTP Protocol - Header #1

YUNU·2023년 8월 23일
http
0

HTTP

목록 보기
10/11
post-thumbnail

🖥️ HTTP Protocol - Header

▪️ 일반적으로 자주 사용하는 헤더

🟦 HTTP 헤더 개요

🔷 헤더 사용 형태

header-field =field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
ex) Content-Type: text/html;charset=UTF-8 , Host: www.google.com

🔷 헤더 용도

HTTP 전송에 필요한 모든 부가 정보를 헤더에 담음
ex)메시지 바디의 내용, 크기 / 인증 / 요청 클라이언트 / 서버 정보 / 캐시 관리정보 등

표준 헤더는 굉장이 많음

필요시 임의의 헤더 추가 가능

🔷 HTTP 표준

1999년 RFC2616 폐기 -> 2014년 RFC7230~7235 등장

Representation = representation Metadata + Representation Data
표현 = 표현 메타데이터 + 표현 데이터

🔹 HTTP BODY message body - RFC7230(최신)

  • 메시지 바디를 통해 표현 데이터 전달

  • 메시지 바디 = 페이로드(payload)

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

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

어떤 리소스를 HTTP를 통해 전송될 때는 HTML로 표현할 수도 있고 JSON으로 표현할 수도 있음

➡️ 실제 데이터를 전달하는 것을 표현이라 함


🟦 표현 헤더

  • Content-Type : 표현 데이터의 형식 설명
    메시지 바디에 들어가는 내용이 무엇인지 -> 미디어 타입, 문자 인코딩
    ex) Content-Type:text/html;charset=UTF-8 , application/json ...

  • Content-Encoding : 표현 데이터의 압축 방식
    표현 데이터를 압축하기 위해 사용

    데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
    ex) Content-Encoding: gzip

    ➡️ 데이터를 읽는 쪽에서 인코딩 헤더의 정보를 가지고 압축 해제

  • Content-Language : 표현 데이터의 자연 언어
    표현 데이터의 자연 언어를 표현함
    ex) Content-Language: ko , en

  • Content-Length : 표현 데이터의 길이(바이트 단위) -> (명확히는 페이로드 헤더)
    ex) Content-Length: 4
    Transfer-Encoding을 사용하면 Content-Length 사용 X


🟦 Content Negotiation (협상 헤더)

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

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

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

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

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

    ex) 선호하는 언어가 한국어일 때
    헤더에 Accept-Language: ko 사용

    ex) 한국어를 요청했으나 서버는 기본적으로 일본어 지원 + 영어 지원하는 경우
    ➡️ 우선 순위 사용

🔹 우선순위

  1. Quality Values(q) - 0~1 (클수록 우선순위 높음)

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

  1. 구체적인 것이 우선

    Accept: text/*, text/plain, text/plain;format=flowerd
    -> 우선순위 순서는 text/plain;format=flowerd ▪️ text/plain ▪️ text/* 순

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


🟦 전송 방식

  • 단순 전송
    메시지 바디에 대한 Content-Length 지정 -> Content-Length를 알고 있을 때

    ex) Content-Length: 1997

  • 압축 전송
    Encoding 방식 헤더에 담아 전송

    ex) Content-Encoding: gzip

  • 분할 전송
    바이트단위로 끊어서 전송

    Content-Length를 넣어서 보내면 안됨(예상 불가 + chunk마다 길이 존재)

    ex) Transfer-Encoding: chunked

  • 범위 전송
    전송 중에 전송이 중단됨
    이후 다시 전송할 때, 처음부터 전송 X

    ex)
    요청 -> Range: bytes=1111-2222
    응답 -> Content-Range: bytes 1111-2222 / 2222


🟦 정보성 헤더

🔷 일반 정보

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

    잘 사용 안함, 검색 엔진에서 주로 사용
    요청에서 사용

  • Referer
    : 현재 요청된 페이지의 이전 웹 페이지의 주소

    (A ➡️ B로 이동) B를 요청할 때 Referer: A를 포함해서 요청
    Referer를 사용해서 유입 경로 분석 가능
    요청에서 사용

  • User-Agent
    : 유저 에이전트(클라이언트) 애플리케이션 정보(ex: 웹 브라우저 정보)

    특정 브라우저에서 버그가 생겼을 때, 로그를 파싱하여 파악 가능
    통계 정보로 사용 가능
    요청에서 사용

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

    응답에서 사용

    ORIGIN 서버
: HTTP요청 보내면 중간에 여러 프록시 서버 거침
 그러한 프록시 서버가 아닌 나의 요청이 도달하여 HTTP 응답을 해주는 서버

  • Date
    : 메시지가 발생한 날짜와 시간

응답에서 사용

🔷 특별 정보

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

    요청에서 사용하며 필수값임

    하나의 서버가 여러 도메인을 처리해야 할 때 구분을 위함
    (하나의 IP 주소에 여러 도메인이 적용되어 있을 때)

    ex) 특정 IP의 서버에 가상 호스트를 통해서 여러 개의 애플리케이션이 구동되어 있는 경우
    Host: ~~~ 헤더를 통해서 구분

  • Location
    : Page Redirection

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

    201(Created): Location 값 = 요청에 의해 생성된 리소스 URI

    3xx(Redirection): Location 값 = 요청을 자동으로 리다이렉션하기 위한 대상 리소스

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

    ex) Allow: GET, HEAD
    POST요청 -> 응답에 405 코드 + Allow: GET, HEAD 반환
    잘 사용 안함

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

    ex) Retry-After:요일, 일 월 년도 시간 GMT or 180(초단위 표기)


🟦 인증 헤더

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

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

    인증에 문제 발생 -> 401 Unauthorized 응답과 함께 사용

 ex) WWW-Authenticate: Newauth realm="\***", type=\**, title=\"***", Basic realm="***"

🟦 쿠키 헤더

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

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

🔹 쿠키 미사용할 경우

유저가 welcome page에 접속하여 로그인
로그인 이후 welcome page에 재접근
➡️ 로그인 이전에 welcome page에 접근한 것과 서버는다름을 구분하지 못함


HTTP는 Stateless 프로토콜(클라이언트와 서버는 서로 상태를 유지하지 않음)이기에
클라이언트와 서버가 요청/응답을 주고 받으면 연결이 끊어짐
클라이언트가 다시 요청을 하면 서버는 이전 요청을 기억하지 못함


❌ 모든 요청과 링크에 사용자 정보를 포함하여 문제 해결
➡️ 보안 + 개발 난해함

⭕ 쿠키 사용

로그인 요청에 user=DDeo99 포함
응답에 Set-Cookie: user=DDeo99 포함하여 전송
웹 브라우저 내부의 쿠키 저장소에 'user=DDeo99' 저장

로그인 이후 welcome page에 접근하면 웹브라우저는 쿠키 저장소를 확인, 조회
서버에 Cookie: user=DDeo99를 포함한 요청 보냄
(모든 요청에 쿠키 정보를 자동으로 포함하여 요청 보냄)

실제로는 로그인이 성공하면 서버에서 session키를 만들어 클라이언트에 반환

ex) set-cookie: sessionId=****; expires=Sun, 28-Aug-2023 19:40:00 GMT; path=/; domain=.google.com; Secure
- 쿠키
🔹 사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹

🔹 쿠키 정보는 항상 서버에 전송
- 네트워크 트래픽 추가 유발 -> 최소한의 정보만 사용해야(세션 id, 인증 토큰)
- 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지 참고

❗ 보안에 민감한 데이터는 절대 쿠키에 저장 X

🔷 쿠키 생명주기

  • expires
    :만료일이 되면 쿠키 삭제

    ex) Set-Cookie: expires=Sun, 28-Aug-2023 19:40:00 GMT

  • max-age
    : 0이나 음수를 지정하면 쿠키 삭제

    ex) Set-Cookie: max-age=6000 (10분)

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

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

🔷 쿠키 도메인

  • domain

    ex) domain=goole.com

▪️ 도메인 명시
: 명시한 문서 기준 도메인 + 서브 도메인 포함해서 쿠키 전송
ex) domain=example.org 지정하여 쿠키 생성
➡️ exmple.org + dev.example.org 쿠키 접근 Ok

▪️ 도메인 생략
: 현재 문서 기준 도메인에만 적용
ex) example.org에서 쿠키 생성, domain 지정 생략
➡️ example.org에서만 쿠키 접근

🔷 쿠키 경로

  • path

    ex) path=/home

    일반적으로 path=/ 루트 로 지정
    경로를 포함한 하위 경로 페이지만 쿠키 접근 가능

🔷 쿠키 보안

  • secure
    https인 경우에만 클라이언트에서 서버로 쿠키 전송

  • HttpOnly
    XSS 공격 방지
    자바스크립트에서 접근 불가, HTTP 전송에만 사용 가능

  • SameSite
    XSRF 공격 방지
    요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송


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

profile
YUNU
DDeo99
이전 포스트

HTTP Protocol - HTTP 상태코드

다음 포스트

HTTP Protocol - Header #2

0개의 댓글