
웹 서버는 반환 데이터를 캐시할지 말지를 결정합니다.
no-store : 캐시 하지 않음.
데이터를 절대 저장하지 않고, 항상 서버에 요청하여 최신 데이터를 가져옵니다.
민감한 정보(예: 개인정보, 금융 데이터) 전송 시 사용됩니다.
no-cache : 캐시 하되, 매번 서버와 재검증 후 사용.
데이터를 캐시로 저장하지만, 사용하기 전에 항상 서버에 유효성을 확인합니다.
서버 응답에 따라 캐시 데이터를 사용할지 결정합니다.
데이터를 저장할 수 있는 위치를 지정합니다. 웹 브라우저(Private Cache)와 프록시(Shared Cache)가 대상입니다.
public : 데이터를 Private Cache(브라우저)와 Shared Cache(프록시) 모두에 저장.
CDN이나 캐시 서버에서도 데이터를 저장해 여러 클라이언트가 공유 가능.
자주 변경되지 않는 리소스(예: 이미지, 스타일시트)에 적합.
private: 데이터를 오직 Private Cache(브라우저)에만 저장.
사용자 개인 데이터를 다룰 때 사용합니다.
Shared Cache(프록시)에는 저장되지 않으므로 데이터 유출 위험이 적습니다.
데이터가 유효한 기간을 설정합니다. 일정 시간이 지나면 서버와 재검증을 수행하거나 데이터를 무효화합니다.
max-age=<초> : 데이터를 캐시한 후 최대 유효 기간(초 단위)을 정의합니다.
이 기간 동안 서버와 재검증 없이 캐시 데이터를 사용합니다.
예: max-age=3600은 데이터를 1시간 동안 유효하다고 간주합니다.
s-maxage=<초> : Shared Cache(프록시)에만 적용되는 유효 기간.
프록시와 같은 중간 캐시 서버의 재검증 주기를 설정합니다.
브라우저의 max-age보다 우선 적용됩니다.
max-age=0는 어떤 의미일까요?
→ no-cache와 동일합니다. 매번 서버와 재검증합니다.
s-maxage=31536000, max-age=0는 어떤 의미일까요?
Shared Cache(프록시)는 1년 동안 유효한 데이터를 사용합니다.
Private Cache(브라우저)는 매번 서버에 재검증을 요청합니다
캐시 데이터를 사용할 때 재검증이 필수인지 여부를 지정합니다.
must-revalidate : 재검증이 필수.
서버와의 연결 문제로 재검증 실패 시 캐시 데이터를 사용하지 않고, 504 Gateway Timeout을 반환합니다.
proxy-revalidate : Shared Cache(프록시)에 대해 must-revalidate를 적용합니다.
서버에 직접 접근할 수 없는 경우 프록시가 데이터를 재검증해야 합니다.
캐싱 전략 중 하나로, 즉시성과 최신성을 모두 제공하기 위해 설계된 HTTP Cache-Control 확장 디렉티브. 캐싱된 데이터가 오래되었더라도 즉시 반환한 뒤, 백그라운드에서 재검증을 수행
stale-while-revalidate=<초>
캐시 데이터가 유효하지 않은 상태라도 지정된 시간 동안 즉시 반환 가능.
이후 백그라운드에서 재검증을 수행해 최신 데이터를 업데이트합니다.
예시
Cache-Control: max-age=1, stale-while-revalidate=60
0~1초: 데이터가 신선 → 캐시 데이터를 그대로 사용. (max-age=1)
1~60초: 데이터가 오래됨 → 캐시 데이터를 반환하며, 재검증 수행. (stale-while-revalidate=60)
60초 이상: 재검증 없이 캐시 데이터를 사용할 수 없음.
장점
즉시성: 캐시된 데이터를 바로 반환해 빠른 응답.
최신성: 백그라운드에서 재검증으로 최신 데이터 보장.
과거에는 Cache-Control을 잘 이해하지 못하고 무작정 모든 옵션을 조합해 사용하던 경우가 많았습니다.
Cache-Control: no-cache, no-store, must-revalidate, max-age=0, s-maxage=0
문제점
서로 충돌하는 옵션(예: no-store와 no-cache)을 동시에 사용.
필요 이상으로 복잡하게 설정해 캐시의 이점을 상실.
올바른 접근
캐시 대상과 상황을 명확히 정의합니다.
필요한 옵션만 선택적으로 설정해 간결성을 유지합니다.