HTTP 헤더

JeongSeulho

2024년 12월 21일

표현 헤더

표현 데이터(BODY)의 내용, 형식, 크기, 압축 등 정보를 알려주는 헤더
요청, 응답 HTTP 메시지 모두에 사용
Content-Type : 표현 데이터의 형식
- 예시 : text/html; charset=utf-8, application/json, image/jpeg
Content-Encoding : 표현 데이터가 어떤 압축 형식으로 인코딩되었는지 알려주는 헤더
- 해당 헤더를 통해 압축 형식을 파악하여 압축 해제 가능
- 예시 : gzip, deflate, identity
Content-Language : 표현 데이터의 자연 언어
- 예시 : ko-KR, en-US
Content-Length : 표현 데이터의 길이를 바이트 단위로 알려주는 헤더
- 이 길이 만큼의 데이터가 오면 데이터 전송이 완료된 것으로 간주
- 단, Transfer-Encoding 헤더가 있으면 Content-Length 헤더를 사용하지 않음
- 예시 : 24(바이트 단위)

0~1 사이의 숫자로 표현, 높을수록 우선순위가 높음
생략 시 1로 간주
예시 : Accept: ko-KR,en-US;q=0.7,en;q=0.3
- 아래와 같은 우선순위
- ko-KR : 1
- en-US : 0.7
- en : 0.3

단순 전송
압축 전송
- 응답의 Content-Encoding 헤더로 압축 인코딩 방식을 알려줌
분할 전송
- 응답의 Transfer-Encoding : chunked로 설정
- 이 경우 Content-Length 헤더는 사용하지 않음
범위 전송
- 중간에 데이터가 끊어지면 전체를 다시 요청하지 않고 필요한 부분만 요청
- 요청의 Range 헤더로 전송 특정 범위의 데이터만 요청(Range: bytes=100-200)
- 응답의 Content-Range 헤더로 전송 범위를 알려줌(Content-Range: bytes 100-200/1000)

Form : 요청한 유저의 이메일 정보
- 크롤링에서 크롤러에게 연락하거나 과도한 크롤링을 방지하기 위해 연락처를 제공
Referer : 이전 웹 페이지 주소
- A => B로 이동하는 경우 B의 HTTP 요청에 Referer: A 헤더를 포함
- 유입 경로 분석
User-Agent : 클라이언트의 애플리케이션(브라우저) 정보
- 서비스의 사용 브라우저 및 버전 정보 분석
- 어떤 종류의 브라우저에서 에러가 나는지 파악
Server : 요청을 처리하는 마지막 서버의 소프트웨어 정보
- 프록시 서버, 캐시 서버 등 요청을 거쳐가는 여러 서버 중 최종 처리하는 마지막 서버의 소프트웨어 정보
Date : 메시지가 발생한 날짜와 시간, 주로 응답에서만 사용

Host : 요청한 도메인 주소
- 요청에서 사용하는 필수 헤더
- 하나의 서버에서 여러 도메인을 처리하는 구조로 되어 있을 때 구분하기 위함
Allow : 허용된 메서드를 알려주는 헤더
- 405 Method Not Allowed 응답에 포함 되는 헤더
Retry-After : 유저가 다시 요청하기까지 기다려야 하는 시간
- 503 Service Unavailable 응답에 포함 되는 헤더
- 얼마나 길게 점검하는지 등을 알려주는 것

Authorization : 인증 정보를 서버에게 전달
- 요청 메시지에서 사용
- Authorization: <인증 타입> <인증 값>과 같이 사용
- 예시 : Authorization: Basic 1234567890, Authorization: Bearer 1234567890
WWW-Authenticate : 리소스 접근에 필요한 인증 방법을 알려주는 헤더
- 401 Unauthorized 응답에 포함 되는 헤더
Set-Cookie : 서버에서 클라이언트로 쿠키 전달하는 헤더
- 예시 : Set-Cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2024 00:00:00 GMT; path=/; domain=.example.org; Secure

cache-control: max-age=60 : 60초간 이 응답을 캐시로 사용하라
cache-control: no-cache : 캐시를 하되, 캐시가 만료되지 않아도 사용하기 전에 항상 Origin 서버에 검증을 해라 => 304 Not Modified 이면 캐시 사용
cache-control: public : public 캐시에 저장 가능
- public 캐시는 많은 사용자가 거치는 중간 프록시 서버의 캐시를 지칭
cache-control: s-maxage=60 : 60초간 이 응답을 public 캐시로 사용하라(public 캐시 전용)
cache-control: private : private 캐시에 저장 가능
- private 캐시는 특정 클라이언트의 캐시를 지칭(즉, 특정 사용자의 PC)

cache-control: no-store : 민감한 정보, 캐시를 하지 않음
cache-control: must-revalidate : 캐시가 만료되면 사용하기전에 Origin 서버에 검증을 해라 => 304 Not Modified 이면 캐시 사용

no-cache는 프록시 서버가 Origin 서버와 통신 못한 경우 프록시 캐시를 반환하며 200 OK 응답을 반환하기도 함
must-revalidate는 프록시 서버가 Origin 서버와 통신 못한 경우 504 Gateway Timeout 응답 등 무조건 오류를 반환

헤더를 사용하여 클라이언트의 캐싱된 데이터를 사용해도 될지 서버에서 알려주며 200 OK 응답을 반환하거나 304 Not Modified 응답을 반환

last-modified : 응답 데이터가 (서버에서) 마지막으로 수정된 시간, 응답 메시지에서 사용
if-modified-since : 캐시 데이터가 서버에서 마지막으로 수정된 시간, 요청 메시지에서 사용
위 헤더를 사용하여 캐시를 검증하는 방법
1. 요청하여 받은 데이터와 last-modified, cache-control 정보를 저장(캐싱)
2. 다음 요청 시 캐시된 데이터가 있는데, 캐시가 만료되어 요청을 진행해야함
3. 요청 메시지에 if-modified-since 헤더에 캐시의 last-modified 정보를 전달
4. 서버는 if-modified-since 헤더를 통해 클라이언트에 캐시된 데이터가 마지막으로 수정된 시간을 확인
5. 만약 캐시된 데이터가 서버의 데이터와 동일하다면 304 Not Modified 응답을 반환하며 데이터를 전달하지 않음
단점 : 캐싱이 가능함에도 캐싱하지 않는 상황 발생
- 데이터를 수정하여 날짜가 다르지만, 데이터 결과는 동일한 경우
- 실제 서비스에 관여하지 않는 변경이지만 수정하여 날짜가 달라지는 경우