이번시간에는 HTTP의 헤더에 대해서 알아보겠습니다.
HTTP 헤더
-HTTP전송에 필요한 모든 부가정보 (메시지 바디 내용/ 바디 크기/ 압축/ 인증 / 요청 클라이언트/ 서버 정보 등등) 포함.
-표준 헤더도 많고 필요시 임의로 헤더 추가 기능도 있습니다.
과거의 HTTP 헤더를 먼저 살펴보면
General 헤더 : 메시지 전체에 적용되는 정보 (요청/응답 관계없이)
Request 헤더 : 요청 정보
Response 헤더 : 응답 정보
Entity 헤더: 엔티티 바디 정보 (엔티티 본문(메시지 바디)를 해석할 수 있는 정보=> 데이터 유형/길이, 압축정보)
하지만 RFC2616 표준에서 2014년 RFC7230~7235 표준이 등장함에 따라 달라진 점이 있습니다.
Entity(엔티티) -> Representation(표현) 으로 바뀐점 입니다.
표현은 요청이나 응답에서 전달할 실제 데이터이고 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다.
Content Type: 표현 데이터의 형식 (html? xml?)
-> 미디어 타입, 문자 인코딩 (UTF-8 , text/html)
Content-Encoding: 표현 데이터의 압축 방식 , 데이터 전달 측에서 인코딩 헤더 추가, 읽는 쪽에서 헤더 보고 압축해제
->ex) gzip , deflate, identity(압축x)
Content Language: 표현 데이터의 자연 언어
->ex) ko(한국), en(영어-영국) , en-US(영어-미국)
Content Length: 표현 데이터의 길이 (바이트 단위)
협상
협상은 콘텐츠 네고시에이션이라고도 불리며 클라이언트가 선호하는 표현을 요청하는 것을 말합니다.
Accept : 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연언어
*협상 헤더는 요청시에만 사용.
클라이언트가 서버에 요청시 선호하는 표현을 헤더에 포함시켜 전달합니다.
예를 들면, 구글과 같이 다국적 기업은 영어로 웹사이트를 표시하는 것이 기본값이지만
한글이 더 익숙한 한국에서는 자연언어를 ko(한글)로 하여 요청을 하는 것이 예시입니다.
단, 협상 헤더에서 어려울 것이 없을 경우가 문제가 될 수 있는데
협상 우선순위를 미리 지정해 둡니다. (Quality Values)
협상 우선순위는 0~1 사이의 값으로 클수록 높은 우선순위를 가지고 , 생략되어 있다면 1로 가정합니다.
위 Accept Language에서 우선순위를 적용한 협상 헤더를 보면
이미지 처럼 헤더에 각 언어에 대한 협상 값 (Value)를 설정하여 요청하고, 값이 높은 언어 순서로 지원합니다
다른 우선순위 방법에는 '구체적인 것'이 있는데
- 구체적인 것이 우선한다는 우선순위가 있습니다.
- 예를 들면- 미디어 타입에서 (Accept)
1.text/plain;format=flowed
2.text/plain
3.text/*
4. */*
위 4가지 타입에서 1>2>3>4 순서로 구체적이라고 말할 수 있습니다.
우선 순위 역시도
이러한 우선순위를 quality value를 두어 정합니다.
실제로 웹 브라우저에서 f12를 눌러 Header 부분을 확인하면 우선 순위 및 헤더의 구성요소를 확인 할 수 있습니다.
전송방식
다음으로 알아 볼 내용은 전송방식 입니다.
http 메시지를 전송하는 방법을 이야기하는 것인데, 전송 방식에는 크게 4가지가 있습니다
- 단순 전송
- 압축 전송
- 분할 전송
- 범위 전송
먼저 단순 전송이란 Content- Length를 알 때 전송하는 방법으로 압축 등이 없을 때
한 번에 http 메시지를 전송하는 것을 말합니다.
압축 전송은 http 메시지를 압축하여 용량을 줄이고 전송하는 것으로
Content-Encoding 부분이 추가되어 메시지를 받은 측에서는 이 부분을 보고 압축을 해제 합니다 .
다음으로 분할 전송은 http 메시지 용량이 너무 큰 경우 이를 분할하여 전송하는 것으로
Content length를 보내지 않습니다. 메시지를 받는 측은 나눠서 보내진 메시지를 오는대로 처리합니다.
마지막으로 범위 전송은 Content-Range를 설정하여 만약 중간에 네트워크가 끊겨 중간부터 받지 못한 경우등에서
필요한 부분만 범위를 지정하여 데이터를 요청하는 것 입니다 .
일반 정보
다음은 http 헤더에 존재하는 일반적인 정보 입니다.
From : 유저 에이전트의 이메일 정보
-> 일반적으로 사용 x , 검색 엔진등에서 주로 사용하고 요청시 사용 (검색엔진 담당자 연락방법)
Referer: 이전 웹 페이지 주소
->현재 요청된 페이지의 이전 웹 페이지 주소
-> 만약 b사이트를 요청했다면 그 유입경로가 어디인지
User-Agent: 유저 에이전트 애플리케이션 정보
->클라이언트의 애플리케이션 정보 (웹 브라우저 정보 등등) -> 어떤 종류의 브라우저에서 장애 발생하는지 파악 가능
Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
->맨 앞시간에서 데이터 요청/전송 시 다양한 노드를 통하여 전달된다 했는데 여기서 진짜 표현데이터를 만들어주는 서버
Date: 메시지가 생성된 날짜
특별한 정보
http 헤더에 존재하는 특별한 정보는
Host: 요청한 호스트 정보(도메인) -> 필수
-> Host: www.google.com 처럼 명시해야한다.
->가상 호스트를 통해 여러 도메인을 처리할 수 있는 서버가 있는데 1개의
서버안에서 다수의 도메인이 돌아갈 수 있기 때문에 명시가 필수적으로 필요하다.
Location: 페이지 리다이렉션
->상태코드에서 자주 등장한 Location이다.
->201 코드에서의 Location은 생성된 리소스의 URI의미 / 300번대 코드에서는 자동 리디렉션을 위한 대상 리소스 의미
Allow: 허용 가능한 HTTP 메서드
->405번(Method Not Allowed) 상태코드에서 응답에 포함해야하는 내용으로
->지원하는 메소드를 표기해야한다 (GET/POST/PUT 등등)
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야하는 시간
->503 상태코드에서 서비스가 언제까지 불능인지 알려줄 수 있는 부분이다.
-> 날짜 표시 / 초단위 표시 로 표현방법이 나뉜다.
인증
1. Authorization : 클라이언트 인증 정보를 서버에 전달
-> 인증 메커니즘에 따라 value 값에 들어갈 값이 달라진다.
2. WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의
-> 401 Unauthorized 응답과 함께 사용된다 .
노란색 괄호 안에 들어간 내용이 필요한 인증방법을 뜻한다.
쿠키
쿠키는 인증된 정보를 표시하는 방법이다. (뒤에서 더 자세히 설명)
Set-Cooke: 서버에서 클라이언트로 쿠키 전달
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
로그인의 상황을 예시로 들면,
홍길동 유저가 로그인을 했고, 서버에서 로그인을 했다는 응답을 받았다.
하지만 http는 무상태 프로토콜이기 때문에, 로그인 페이지에서 로그인을 하고 다른 페이지로 돌아가면
홍길동이 로그인 했다는 사실을 잊어먹는다
때문에 로그인을 해도 다른 페이지에 접근 할 경우 모든 요청에 사용자 정보를 입력해야한다.
하지만 이것은 단편적인 예시이고, 실제로는 아이디/ 비밀번호 등등 많은 개인정보를 요청해야 하기 때문에
보안적인 문제도 있고, 매 요청마다 모든 정보를 같이 보내야하므로 번거로운 문제점도 존재한다.
이러한 문제점을 해결하기 위해 쿠키라는 개념이 사용된다.
간단한 흐름을 보자면,
먼저, 웹브라우저에게 Set-Cookie로 쿠키를 설정하여 주고, 웹브라우저 내부의 쿠키 저장소에 설정한 쿠키를 저장한다.
이후 다른 페이지에 접근 할 경우, 받은 쿠키를 포함하여 요청을 보낸다.
이 쿠키는 일일이 입력하는 것이 아니라, 모든 요청에 쿠키 정보가 자동으로 포함되게 된다.
-쿠키는 사용자 로그인 세션 관리 또는 광고 정보 트래킹의 경우 주로 사용되며
-쿠키 정보는 항상 서버에 전송된다.
-하지만 이 역시도 무상태 프로토콜의 원리와 비슷하게 최소한의 정보만을 사용해야한다 (세션id, 인증 토큰)
-또한, 보안에 민감한 데이터는 저장하면 안된다( 주민번호, 카드번호)
쿠키의 대략적인 생김새는 아래와 같다.
expires에는 쿠키의 만료일 (만료일이 되면 쿠키 삭제) or max-age=3600 (3600 초 뒤에 쿠키 만료)
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
'HTTP' 카테고리의 다른 글
| HTTP 헤더2 캐시와 조건부 요청 / 프록시 캐시 (HTTP 김영한) (2) | 2024.01.08 |
|---|---|
| HTTP 상태코드 (http 김영한) (0) | 2024.01.07 |
| HTTP API 설계 (GET/POST/PUT/PATCH/DELETE) (김영한 HTTP) (0) | 2024.01.06 |
| HTTP 서버 (김영한 HTTP) (0) | 2024.01.06 |
| HTTP URI/URL/URN (김영한 http) (1) | 2024.01.06 |