Cache-Control 헤더는 캐시에 관련된 HTTP 표준 헤더로 HTTP/1.1 버전에 도입되었다. 여기서 말하는 캐시는 브라우저의 캐시(사설 캐시) 뿐만 아니라 프록시 서버의 캐시(공유 캐시)도 포함된다.
일반적으로 사용되는 디렉티브는 다음과 같다.
seconds
>no-store 디렉티브는 캐싱을 하지 않겠다.
라는 뜻이며 해당 헤더를 브라우저가 응답 받을 경우 response를 캐싱하지 않는다. SPA(Single Page Application)에서 라우팅 변경이나 뒤로가기/앞으로가기를 통해 다시 요청이 필요할 경우에 무조건 다시 요청한다.
예를 들어 리액트로 작성된 프로젝트에서 A
컴포넌트에서 <img src="/apple.jpg" />
가 렌더링 되고 있는 상태에서 라우팅 변경으로 B
컴포넌트가 렌더링 되었다가 다시 라우팅 변경으로 A
컴포넌트가 렌더링 된다면 브라우저는 다시 appl.jpg
를 서버로 GET 요청한다.
no-cache 디렉티브는 뜻 그대로 해석하자면 no-store처럼 캐싱을 하지 않겠다.
라고 오해할 수 있지만 캐싱을 하지만 변경 되었는지 확인하겠다.
이다. 서버에서 200응답 오면 해당 응답을 사용하지만 304응답(not-modified)이 오면 캐싱했던 응답을 재사용한다. 매번 요청을 보내야 되긴 하지만 변경되지 않았을 경우에는 캐싱된 응답을 사용하면 되기 때문에 빠르고 사이즈가 작은 응답을 받을 수 있다.
SPA(Single Page Application)에서 라우팅 변경이나 뒤로 가기/앞으로 가기
를 하게 되면 실제로 요청을 보내지 않고 캐싱된 데이터를 사용한다.
예를 들어 리액트로 작성된 프로젝트에서 A
컴포넌트에서 <img src="/apple.jpg" />
가 렌더링 되고 있는 상태에서 라우팅 변경으로 B
컴포넌트가 렌더링 되었다가 다시 라우팅 변경으로 A
컴포넌트가 렌더링 된다면 브라우저는 다시 appl.jpg
를 서버로 GET 요청하는 것이 아닌 기존의 응답을 재사용한다.
seconds
>max-age 디렉티브는 응답을 받은 뒤 지정한 시간동안에만 캐싱된 응답을 재사용하고 지정된 시간이 지나면 서버로 다시 요청한다. 만약 304(not-modified) 응답을 받게되면 캐싱된 응답의 캐싱시간을 지정한 시간만큼 연장한다.
매커니즘상 max-age=0
은 no-cache
와 같다고 볼 수 있다. 따라서 마찬가지로 SPA에서 라우팅 변경시 지정한 시간이 지났다고 해서 다시 서버에 요청하지 않는다.