HTTP - header1

HTTP header 개요

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

ex) 메세지 바디의 크기, 압축, 인증, 요청 클라이언트 등등... 헤더는 종류가 너무 많다... 심지어 필요시 임의의 헤더 추가도 가능

 

header 필드의 문법

-> field-name":" OWS field-value OWS

* field-name은 대소문자 구분X, OWS: 띄어쓰기 허용

이전의 RFC에서는 '엔티티'라고 불렀지만 지금의 RFC에서는 '표현'이라고 부름

메세지 본문을 통해 표현 데이터를 전달하고 메세지 본문은 payload라고 부른다.

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

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

 

헤더의 종류

기본 헤더

Content-Type: 표현 데이터의 형식 (미디어 타입, 문자 인코딩)

* application/json, image/png 등

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

* 데이터를 전달하는 곳(서버)에서 압축 후 인코딩 헤더 추가 (gzip, deflate, identity 등)

Content-Language: 표현 데이터의 자연 언어 (ko, en 등)

Content-Length: 표현 데이터의 길이 (바이트 단위, Transfer-Encoding을 사용하면 이 필드 사용 X)

 

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

-> 클라이언트가 선호하는 표현 요청 (요청시에만 사용)

Accept: 선호하는 미디어 타입

Accept-Charset: 선호하는 문자 인코딩

Accept-Encoding: 선호하는 압축 인코딩

Accept-Language: 선호하는 자연 언어

 

협상은 우선순위를 가질 수 있음(Quality Values(q)값 사용)

또한 구체적일수록 우선순위가 높고 구체적인 것을 기준으로 미디어 타입을 맞춤

0부터 1까지 실수로 표현하며 클수록 높은 우선순위를 가짐 (생략하면 1)

ex) Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8, en;q=0.7

 

전송 방식 헤더

HTTP의 전송 방식은 다음과 같은 4종류가 있다.

1. 단순 전송

2. 압축 전송

3. 분할 전송 -> content-length 사용 불가능(분할하기 때문에 예측할 수 없음)

4. 범위 전송

 

Transfer-Encoding: 분할, 압축 전송(생략시 단순, gzip, chunked 등)

Range, Content-Range: 범위 전송 (요청 받은 범위를 포함)

 

일반 정보 헤더

From: 유저 에이전트의 이메일 정보(요청에서 사용)

* 일반적으론 잘 사용되지 않으며 검색엔진 같은 곳에서 종종 사용

Referer: 이전 웹 페이지의 주소(요청에서 사용)

* A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청

* 유입경로 분석 가능 (Referrer의 오타이다!)

User-Agent: 유저 에이전트의 애플리케이션 정보(요청에서 사용)

* 웹 브라우저 정보 등을 포함

* 통계 정보에서 사용할 수 있음(어떤 종류의 브라우저에서 장애가 발생하는지 등)

Server: 요청을 처리하는 본 서버의 소프트웨어 정보(응답에서 사용)

Date: 메세지가 생성된 날짜(응답에서 사용)

 

특별한 정보 헤더

Host:요청한 호스트 정보(도메인, 요청에서 사용)

* 필수!

* 하나의 서버가 여러 도메인을 처리해야 할 때

Location: 페이지 리다이렉션

* 웹 브라우저는 3xx 응답 결과에 이 헤더가 있다면 해당 위치로 자동 이동(리다이렉트)

Allow: 허용 가능한 HTTP 메서드(응답에서 사용)

* 405에서 응답에 포함

Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간(응답에서 사용)

* 503에서 사용 가능 (서비스가 언제까지 불능인지) -> 근데 이거 사실 예측하기가 힘들다...

 

인증 헤더

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

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

* 위에 나온 401의 응답과 함께 사용

 

쿠키 헤더

쿠키는 HTTP의 Stateless와 밀접한 연관이 있음

Stateless라면 서버는 클라이언트의 상태를 저장하지 않는데, 그럼 매 요청에 사용자 정보를 포함하는가??

만약 그렇다면 모든 요청에 사용자 정보가 포함되도록 클라이언트측이 개발해야하고, 브라우저를 종료 후 다시 열면 초기화 된다는 단점이 있음.

해당 문제를 해결하기 위해 사용자 정보를 브라우저의 쿠키에 저장하고 모든 요청에 쿠키 정보를 자동으로 포함되게 하면 해결할 수 있음.

 

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

* expires(만료일 지정), max-age(남은 시간 지정)로 생명 주기 관리 가능

* domain으로 어느 도메인에서 쿠키 접근이 가능한지 설정(명시하면 명시한 문서 기준 도메인 + 서브 도메인 포함하여 접근 가능, 생략한다면 현재 문서 기준 도메인만 적용)

* path로 접근 가능한 리소스 경로 지정 가능 (명시된 경로를 포함한 하위 경로 페이지만 쿠키 접근 가능)

* secure로 https인 경우에만 전송하도록 지정 가능

* HttpOnly로 HTTP 전송에만 사용하도록 지정(XSS 공격 방지, js에서 접근 불가)

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

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

 

쿠키는 사용자 세션 관리, 광고 정보 트래킹 등에 사용된다. 

또한 쿠키 정보는 항상 서버에 전송되기 때문에 최소한의 정보만 사용해야한다.(네트워크 트래픽 추가 유발하기 때문) + 보안에 민감한 데이터는 저장하면 안 됨(개인정보)