https://developer.mozilla.org/ko/docs/Web/HTTP/Headers 에서 보듯이 HTTP의 헤더는 꽤나 많다.
그 중에서 자주 사용하는 것 같은 헤더에 정리해보려 한다.
HTTP 헤더는 크게 request 헤더, response 헤더로 나뉘고 둘 다 사용하는 경우도 있다.
표현 헤더
먼저 메세지의 표현과 관련된 Content-xxx 헤더가 있다.
표현 헤더는 요청, 응답 둘 다 사용될 수 있으며 4가지정도만 알아보겠다.
Content-Type - 표현 데이터의 형식
Content-Encoding - 표현 데이터의 압축 방식
Content-Language - 표현 데이터의 자연 언어
Content-Length - 표현 데이터의 길이
설명과 그대로 표현 데이터와 관련된 헤더이다.
Content-Type을 예로 들겠다.
요청에서 사용할 때 서버 입장에서는 클라이언트가 보내는 메세지 바디가 어떤 형식인지 알지 못한다.
따라서 요청 헤더의 Content-Type을 확인하여 메세지를 해석할 수 있다.
응답에서 사용할 때 클라이언트 입장에서는 서버가 보내는 메세지 바디가 어떤 형식인지 알지 못한다.
따라서 응답 헤더의 Content-Type을 확인하여 메세지를 해석할 수 있다.
협상 헤더
이전에 Content-Type 헤더와 헷갈렸던 헤더가 있는데 바로 협상과 관련된 Accept 헤더이다.
이 헤더는 요청시에만 보낼 수 있으며 말 그대로 서버 측한테 타입, 인코딩과 관련된 협상을 하는 것이다.
그로 인해 서버는 클라이언트가 보낸 Accept 관련 헤더를 확인하여 클라이언트 별로 다른 응답을 내릴 수 있게 된다.
Accept - 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset - 클라이언트가 선호하는 문자 인코딩
Accept-Encoding - 클라이언트가 선호하는 압축 인코딩
Accept-Language - 클라이언트가 선호하는 자연 언어
Accept 헤더는 우선순위를 지정할 수 있으며 언어 관련 헤더를 예로 들겠다.
클라이언트가 Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 로 보내면 서버는 헤더를 확인하여 우선순위가 제일 높은 부분에 대해서 응답해준다.
만약 서버측에 응답해줄 수 있는 것이 없다면?
협상이 제대로 진행되지 않은 것이므로 데이터를 응답해주지 못하는 것이 맞다.
따라서 HTTP STAUS 406 Not Acceptable를 응답할 수 있다.
근데 실제로는 이 오류는 거의 사용되지 않는다고 한다.
최종 사용자가 이해하기 어렵고 수정하기 어려운 이 오류 코드를 사용하여 응답하는 대신 서버는 관련 헤더를 무시하고 사용자에게 실제 페이지를 제공한다.
그 이유는 사용자가 완전히 만족하지 않더라도 오류를 내는 것 보다는 낫기 때문이다.
일반 정보
From - 유저 에이전트의 이메일 정보
요청에서 사용하고 일반적으로 잘 사용하지 않는다.
Referer - 이전 웹 페이지 주소
요청에서 사용하고 유입 경로 분석 가능, referer의 올바른 철자는 referrer이다.
User-Agent - 유저 에이전트 애플리케이션 정보
요청에서 사용하고 통계 정보 파악이나 어떤 브라우저에서 장애가 발생하는지 파악이 가능하다.
Server - 요청을 처리하는 오리진 서버의 소프트웨어 정보
응답에서 사용
Date - 메시지가 생성된 날짜
응답에서 사용
특별한 정보
Host - 요청한 호스트 정보(도메인)
하나의 서버가 여러 도메인을 구동하는 경우 그 도메인을 구분하기 위한 헤더(가상호스트)
Location - 페이지 리다이렉션
Allow - 허용 가능한 HTTP 메서드
Retry-After - 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
인증
Authorization - 클라이언트 인증 정보를 서버에 전달
인증 방식(JWT, Session)에 따라 value 값이 다르다.
WWW-Authenticate - 리소스 접근시 필요한 인증 방법 정의
401 Unauthorized 응답과 함께 사용된다.
쿠키
Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달(요청)
클라이언트는 요청 마다 쿠키를 함께 전송한다.
따라서 최소한의 정보만을 사용하는 것이 좋으며 쿠키의 단점을 개선하기 위한 웹 스토리지 기술도 등장했다.
쿠키 - 생명 주기
Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
만료일이 되면 쿠키 삭제
Set-Cookie: max-age=3600 (3600초)
0이나 음수를 지정하면 쿠키 삭제
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
쿠키 - 보안
Secure
쿠키는 http, https를 구분하지 않고 전송
Secure를 적용하면 https인 경우에만 전송
HttpOnly
XSS 공격 방지
자바스크립트에서 접근 불가(document.cookie)
HTTP 전송에만 사용
SameSite
XSRF 공격 방지
요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
캐시
웹브라우저는 대부분 자동 캐시 기능을 사용한다.
캐시를 사용하면 효율적인 통신이 가능하다.
캐시를 사용할 수 있따면 다시 다운로드 받지 않지만 캐시 가능한지의 여부는 통신을 해야함
Last-Modified 헤더와 ETag 헤더로 캐시를 검증할 수 있다.
If-Modified-Since 헤더는 Last-Modified 헤더를 사용하고 If-None-Match 헤더는 ETag 헤더를 사용한다.
If-Modified-Since, Last-Modified는 날짜를 기준으로 if-None-Match, ETag는 임의의 고유한 이름을 사용한다.
각 헤더가 사용하는 필드의 값이 같으면 같은 데이터로 판단한다.
데이터가 갱신됐으면 200 OK + 메시지 바디를 포함한 응답 갱신되지 않고 기존걸 그대로 사용하면 304 Not Modified + 헤더 메타 정보만 응답한다.
Last-Modified, If-Modified-Since의 단점은 1초 미만 단위로 캐시 조정이 불가능하다.
그리고 같은 데이터를 수정해서 데이터 결과가 똑같은 경우에도 갱신하게 된다.
또, 서버에서 별도의 캐시 로직을 관리할 수 없다.
따라서 위의 단점을 해결하고 싶을 때는 ETag를 사용하면 된다.
캐시 제어 헤더
Cache-Control: 캐시 제어
Pragma: 캐시 제어(HTTP 1.0 하위 호환)
Expires: 캐시 유효 기간(하위 호환)
Cache-Control
Cache-Control: max-age
캐시 유효 시간, 초 단위
Cache-Control: no-cache
데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
Cache-Control: no-store
데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate
캐시 만료 후 최초 조회시 원 서버에 검증해야함
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
no-cache vs must-revalidate
no-cache
원 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수도 있다.
오류보다는 오래된 데이터라도 보여주자.(no-cache의 정책이고 협상 관련 헤더의 정책과 비슷하다.)
must-revalidate
매우 중요한 돈과 관련된 결과라면 원 서버에 접근할 수 없는 경우 항상 오류가 발생해야 함
Cache-Control: public
응답이 public 캐시에 저장되어도 됨
Cache-Control: private
응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
Expires
expires: Mon, 01 Jan 1990 00:00:00 GMT
지금은 더 유연한 Cache-Control: max-age 가 권장된다.
같이 사용되면 Expires는 무시된다.
캐시 무효화
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
위와 같이 설정하면 캐시를 무효화시킬 수 있다.
pragma 헤더를 지정하지 않으면 하위 프로토콜에서 캐시되어 동작할 가능성이 있다.
출처
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC