[HTTP] HTTP 헤더 - 일반 헤더

HTTP 헤더 개요

HTTP 헤더

header-field = field-name ":" OWS(띄어쓰기 허용) field-value OWS

• HTTP 전송에 필요한 모든 부가정보

HTTP BODY

message body - RFC7230(최신)

• 표현 = 표현 메타데이터 + 표현 데이터
  (Representation = representation Metadata + Representation Data)
• 메시지 본문(message body)을 통해 표현 데이터 전달
• 메시지 본문 = 페이로드(payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

표현

• 회원이라는 리소스를 html이라는 표현으로 전송할 것인지 json이라는 데이터의 표현으로 전송할 것인지
• 리소스는 추상적, 이것을 클라이언트와 서버간에 서로 주고 받을 때는 서로 이해할 수 있는 무언가로 변환해서 주고 받음
• 표현 헤더는 전송, 응답 둘다 사용

표현 구조

• Content-Type : 표현 데이터의 형식
  • content body에 들어가는 내용이 뭔지? (html, json 등..)
  • 미디어 타입, 문자 인코딩
• Content-Encoding : 표현 데이터의 압축 방식
  • 표현 데이터를 압축하기 위해 사용
  • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
  • 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• Content-Language : 표현 데이터의 자연 언어
  • 표현 언어의 자연 언어를 표현 (ko, en 등..)
• Content-Length : 표현 데이터의 길이
  • 바이트 단위
  • Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨 > Transfer-Encoding 내에 그러한 정보들이 다 포함되어 있음

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

• 클라이언트가 선호하는 표현을 서버에게 요청
• 서버는 클라이언트가 원하는 우선순위에 맞춰서 표현데이터를 제작
• 서버가 못 줄 수도 있지만 최대한 서버가 노력해달라고 클라이언트가 요청
• 협상 헤더는 요청시에만 사용

협상 종류

• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

협상과 우선순위

Quality Values(q)

1. 클수록 높은 우선순위(0~1), 생략하면 1
   Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

2. 구체적인 것이 우선
   Accept: text/*, text/plain, text/plain;format=flowed, */*
   - text/plain;format=flowed이 1순위
   

3. 구체적인 것을 기준으로 미디어 타입을 맞춤
   Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
   

- text/html은 딱 맞는것이 있지만 text/plain은 text/*;q=0.3에 매핑

전송 방식

• 단순 전송
  • Content-Length를 지정 > Content의 길이를 알 수 있을 때 사용
  • 한번에 요청하고 한번에 쭉 받음
• 압축 전송
  • 서버에서 압축 > 용량이 줄어듦
  • Content-Encoding을 추가로 전송 > 클라이언트가 받고 풀 수 있도록
• 분할 전송
  • Transfer-Encoding: chunked
  • 용량이 큰 것은 분할해서 전송하면 속도 향상 가능
  • 분할 전송을 사용하면 Content-Length를 넣으면 안됨 > 예상이 되지 않기 때문
• 범위 전송
  • 범위를 지정해서 요청
  • 클라이언트 Range: bytes=1001-2000
    서버 Content-Range: bytes 1001-2000 / 2000

일반 정보

• From
  • 유저 에이전트의 이메일 정보
  • 일반적으로 잘 사용하지 않음
  • 요청에서 사용
• Referer
  • 현재 요청된 페이지의 이전 웹 페이지 주소
  • Referer를 사용해서 유입 경로 분석 가능
  • 요청에서 사용
• User-Agent
  • 유저 에이전트 애플리케이션 정보 (클라이언트의 애플리케이션 정보)
  • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
  • 통계 정보
  • 요청에서 사용
• Server
  • 요청을 처리하는 오리진 서버(요청에 실제 응답을 해주는 서버)의 소프트웨어 정보
  • 응답에서 사용
• Date
  • 메시지가 생성된 날짜
  • 응답에서 사용

특별한 정보

• Host

  • 요청한 호스트 정보(도메인)
  • 요청에서 사용
  • 필수 헤더
  • 하나의 서버가 여러 도메인을 처리해야 할 때
  • 하나의 IP 주소에 여러 도메인이 적용되어 있을 때

• Location

  • 페이지 리다이렉션
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
  • 201(Created) 응답코드에서의 Location 값은 요청에 의해 생성된 리소스 URI

• Allow

  • 허용 가능한 HTTP 메서드
  • Allow: GET, HEAD, PUT일때 POST 요청이 오면 405 오류를 내면서 응답에 Allow: GET, HEAD, PUT를 넣고 이정도만 지원을 한다고 보내줌
  • 거의 구현되어있지 않음

• Retry-After

  • 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
  • 503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
  • 날짜 표기 or 초 단위 표기
  
  

인증

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

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

  • 401 Unauthorized 오류가 발생 할 때 넣어줌
  
  

쿠키

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

쿠키 미사용 시

• HTTP는 무상태(Stateless) 프로토콜
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어짐
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못함
• 클라이언트와 서버는 서로 상태를 유지하지 않음
  ->> 쿠키 사용해야 함!

쿠키 사용 시
1. 웹 브라우저가 POST로 로그인
2. 서버는 Set-Cookie 헤더를 사용해서 유저 정보를 넣고 응답
3. 웹 브라우저는 내부의 쿠키 저장소에 유저 정보를 저장
4. 로그인 이후에 웹브라우저가 접속하면 자동으로 웹브라우저는 쿠키를 뒤져서 쿠키 값을 꺼냄
5. 웹브라우저는 Cookie 헤더에 유저 정보를 넣어서 서버에 보냄
6. 서버는 이제 유저를 알 수 있음

• 쿠키는 모든 요청에 쿠키 정보를 자동으로 포함
• 쿠키 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)
• 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

쿠키 - 생명주기

• Set-Cookie : expires=
  • 만료일이 되면 쿠키 삭제(날짜)
• Set-Cookie : max-age=
  • 0이나 음수를 지정하면 쿠키 삭제(초 단위)
• 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

• 도메인을 지정
• 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함해서 적용
• 생략 : 현재 문서 기준 도메인만 적용 (하위 도메인에서는 쿠키 접근 불가능)

쿠키 - 경로

• 도메인으로 한번 필터를 하고 도메인 안에 있는 경로로 추가 필터
• 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
• 일반적으로 path=/ 루트로 지정

쿠키 - 보안

• Secure
  • 쿠키는 http, https를 구분하지 않고 전송
  • Secure를 적용하면 https인 경우에만 전송
• HttpOnly
  • XSS 공격 방지
  • 자바스크립트에서 접근 불가(document.cookie)
  • HTTP 전송에만 사용
• SameSite
  • XSRF 공격 방지
  • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송 가능

출처
모든 개발자를 위한 HTTP 웹 기본 지식