7. HTTP 헤더 개요

• HTTP 헤더 용도 : HTTP 전송에 필요한 모든 부가 정보

 

1. RFC 2616(과거) - > RFC7230~7235(현재) 변화

 

• 과거

과거: 헤더와 바디의 명칭 *과거 헤더의 분류

• 과거에는 헤더를 request,repond,general,entity 로 분류했고 메시지 바디 이름 또한 엔티티 본문이라 명했다.

 

• 현재

현재: 헤더와 바디의 명칭 *헤더의 분류는 따로 없다

• 현재에는 표현 헤더, 표현 데이터(=메시지 본문)로 단순하게 분류한다.
• 참고  표현 = 표현 메타데이터(= 표현 헤더) + 표현 데이터(=페이로드 메시지)
• 표현 종류로 표현,협상 등등 나누었는데 역할에 따라 이해하기 쉽게 분류한 것일뿐 표현 메타데이터란 영역안에 같이 있는 것들이다.

 

 

2. 표현 종류 - 표현

 

• 표현 헤더: 전송, 응답 둘 다 사용

 

1. Content-Type: 표현 데이터의 형식
   • 미디어 타입, 문자 인코딩   ex) text/html; charset=utf-8,   application/json,   image/png
     
     
2. Content-Encoding: 표현 데이터의 압축 방식
   • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가  - > 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
   • ex) gzip, deflate, identity(압축 안함)
     
     
3. Content-Language: 표현 데이터의 자연 언어
   • ex) ko, en, en-US
     
     
4. Content-Length: 표현 데이터의 길이
   • 바이트 단위 
   • 주의: Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨
   • ex) Content-Length: 5

 

 

3. 표현 종류 - 협상(Content negotiation)

 

• 협상 헤더는 요청시에만 사용
  
  
• 용도
  • 자신의 기능에 가장 적합한 버전을 지정할 수 있도록 '동일한 URI에서 문서의 다른 버전'을 제공할 수 있도록 하는 표현 요청
  • ex) 협상 기능을 사용하면 영어로 된 문서를 한국어로 받아볼 수 있다.(문서가 한국어 버전을 만들어놓았다고 가정)
  • 한국어가 없을 시 그 다음 순위로 설정한 언어로 받아볼 수 있다.

 

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

 

 

• 협상의 우선순위
  1. Quality Values(q)
     • 0~1, 클수록 높은 우선순위, 생략시 1(default value)
     • ex) 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  >  text/plain  >  text/*  >  */*
       
       
  3. 구체적 + q 값 - 여기까지 갈 일 없음

 

 

 

4. 전송 방식 - 응답

 

 

• 단순 전송

 

• 압축 전송

• 분할 전송

content-Length 사용 못함

• 범위 전송

 

1001까지는 리소스 받았으니깐 나머지만 넘겨라는 뜻

 

 

5. 표현 종류 - 일반 정보

 

 

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

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

 

Referer: 이전 웹 페이지 주소

요청에서 사용, 유입 경로 분석 가능 (네이버에서 들어왔는지 구글에서 들어왔는지)

 

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

요청에서 사용, client web 브라우저 정보 -> 어떤 종류의 브라우저에서 장애가 발생하는지 파악가능

 

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

응답에서 사용,  프록시 서버 말고 진짜 원서버(=오리진 서버) 정보 받음

 

Date: 메시지가 생성된 날짜

응답에서 사용,  메시지가 발생한 날짜와 시간

 

 

 

6. 표현 종류 - 특별 정보

 

 

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

    요청에서 사용, 필수, 하나의 서버(하나의 IP 주소)가 여러 도메인을 처리해야 할때

    ex) 가상호스트는 하나의 IP 서버 안에 여러 도메인을 한번에 처리할 수 있다.

          그래서 IP주소로 요청을 보냈는데 그 안에서 어떤 도메인으로 가야할지 생기는 문제를 해결한다.

 

Location: 페이지 리다이렉션

    3xx 응답에 Location 헤더가 존재시 location 위치로 리다이렉트함

    201(created) 로 재응답: Locatoin 값은 요청에 의해 생성된 리소스 URI 이기 때문

 

Allow: 허용 가능한 HTTP 메서드

    403 응답에 포함해야함. 

    ex)  Allow: GET, HEAD, PUT  -> get, head, put만 지원합니다 뜻

 

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

    503: 서비스가 언제까지 불능인지 알려줄 수 있음 - 날짜 표기(잘 안씀), 초단위 표기(권장)

 

 

7. 표현 종류 - 인증

 

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

    인증은 여러 메커니즘이 있어서 나중에 공부해서 추가 하기

    HTTP 관련 인증 Authorization은 메커니즘과 관계 없이 header 제공

 

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

    401 응답과 함께 사용

 

 

 

8. 표현 종류 - 쿠키

 

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

 

 

생긴 이유

    HTTP는 무상태 프로토콜이여서 서버는 클라이언트가 재요청을 할 때 이전 요청을 기억하지 못한다.

    ex) 로그인을 하고 페이지 새로고침시 로그아웃 상태로 되돌아가진다.

 

1. 대안

     모든 요청 파라미터에 사용자 정보를 다 넣는다.

    문제점: 보안 취약, 너무 많은 정보시 기입에 힘들다. 브러우저 완전히 종료시 로그인 되었는지 미지수

 

2. 대안

    쿠키 사용

    

    ex) 로그인 요청 -> Set-Cookie: user=woowee 헤더를 응답으로 보냄 -> web browser내에 존재하는 쿠키 저장소에 user=woowee 저장 -> 재요청 시작 -> web browser는 이제부터 먼저 쿠키 저장소부터 조회 -> 쿠키 존재시 - HTTP header(Cookie: user=woowee) 만들어서 요청에 같이 보냄 -> 서버가 이전 요청 기록 기억할 수 있음

 

좌: 첫 로그인    우: 로그인 후 재 접속

 

정리

set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure 

    사용: 사용자 로그인 세션 관리, 광고 정보 트래킹

    쿠키 정보는 항상 서버에 전송 -> 네트워크 트래픽 추가 유발, 최소한의 정보만 사용(sessionID), 민감한 정보는 저장 하면 안됨.

*쿠키와 세션 정리 블로그: https://interconnection.tistory.com/74

* 쿠키: header 저장 * 캐시: body 저장

 

 

 

• 내부속성
  
  
  1.  생명주기
     1. Expires : 만료일 작성
     2. Max-age : 초 작성
     3. 세션쿠기: 만료날짜 생략시 브라우저 종료시 까지 유지
     4. 영속쿠키: 만료 날짜 입력시 만료 날짜 까지 유지
        
        
  2. 도메인
     1. 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
     2. ex) naver.com 쿠키 생성되면 webtoon.naver.com 도 접근 가능
        
        
     3. 생략: 현재 문서 기준 도메인만 적용
     4. ex) naver.com만 쿠키 접근 가능
        
        
  3. 경로
     1. 경로를 포함한 하위 경로 페이지만 쿠키 접근
     2. 어지간 하면 path= /    로 지정
        
        
  4. 보안
     1. secure : https인 경우만 쿠키 전송
        
        
  5. HttpOnly
     1. XSS 공격 방지, JS에서 접근 불가(document.cookie), HTTP 전송에만 사용
        
        
  6. SameSite
     1. XSRF 공격 방지
     2. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

 

 

 

 

- 나중에 정리할 글- 

https://www.youtube.com/watch?v=OpoVuwxGRDI 

https://www.youtube.com/watch?v=1QiOXWEbqYQ 

쿠키, 세션, 인증, 인가, 토큰, 캐시 (나중에 작성 할 것)

stateless인 http에서 내가 서비스에서 이동할 때 data를 계속 유지할 수 있는 방법은 2가지가 존재

1. 내 로컬에 저장하는 법: 쿠키 2. 서버측 session db에 저장하는 것 : 세션 - 중요 정보들

로그인이 된 상태도 뭔가 생성된 상태인 것이다. -> 로그인 상태를 유지하기 위해서 session 사용 

세션은 세션id를 통해서 session에 접근, cookie에 session id 넣어짐

로그인(id, pw) 요청 -> 서버쪽에서 인증을 거침 -> 인증이 완료되면 -> 로그인 된 상태를 넘겨줌 -> 이때 쿠키를 이용하면 쿠키에 내가 로그인 되었다는 정보를 넘겨줌(보안상 위험) / session을 이용하면 쿠키에 session id만 담아서 넘겨줌 -> 재 접속시(유효기간 이내에서) -> 쿠키는 쿠키 저장소에서 다이렉트로 data넘김 / session은 sessionID만 넘긴다 그리고 sessionID를 받은 서버가 sessionDB에서 동일한 sessionID가 존재하는 지 확인 후 있으면 넘기

db[id:123, pw:321, 이런 저런 개인 정보 ]  - sessiondb[ sessionID: qweqwe, id:123, pw:321, 이런저런 정보] - 이렇게 로그인 된 정보를 넘길 수 있다. 이러면 해커나 다른 사람들이 sessiondb를 침투하지 않는 이상 data 유출 위험도가 현저히 낮아진다.

문제점: 세션은 항상 서버측에서 건들여야하므로 시간도 오래 걸리고 유저가 많을수록 db 사용량이 엄청 늘어난다. = 비용

장점: server가 정보를 컨트롤 할 수 있어서 강제탈퇴 할 수 있다. 

jwp: session 방식보다 빠르고 db를 안쓰게 하고 싶어서 json 형식으로 만듬. 토큰을 이용 [형식:json, 페이로드 스트링 = 인코딩 된 값, 어떤 암호방식을 통한 결과값(=서명)]- 서버의 키(암호 결과값 만들어주는 것)에 페이로드 스트링을 넣어서 돌릴 때 결과값과 일치하는지 확인. 내용(페이로드)을 바꿀 때마다 서명이 달라짐 -> 이걸로 상대 정보 접근 막음

쿠키 - 쿠키 with 세션

토큰 - 토큰 with jwp

토큰은 쿠키와 달리 용량 제한이 없다.

 

 

 

 

 

 

 

이전 발행글

2023.01.19 - [spring/HTTP] - HTTP 상태코드

HTTP 상태코드

 

다음 발행글

2023.01.23 - [spring/HTTP] - HTTP 헤더-캐시와 조건부 요청

HTTP 헤더-캐시와 조건부 요청

 

 

---

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