재사용해도 안전할 때만 안전한 캐시입니다
- 1 · 분류
같은 응답을 받아도 되는 사용자를 정합니다
Private cache는 한 사용자 에이전트에 속합니다. CDN 같은 shared cache는 저장한 응답 하나를 여러 사용자에게 재사용할 수 있습니다. 수명을 정하기 전에 이 경계를 명시하세요.[1][2]
- 2 · 키
표현을 바꾸는 입력을 모두 식별합니다
요청 method와 target URI는 최소 캐시 키를 이룹니다. 요청 헤더에 따라 응답이 달라지면 Vary가 저장된 표현을 선택할 때 해당 헤더를 키에 포함하도록 알립니다.[1][4]
- 3 · 통제
저장과 신선도를 따로 정합니다
Cache-Control은 저장과 재사용을 구분합니다. no-store는 저장을 막고, no-cache는 재사용 전에 검증하게 하며, private는 공유 캐시를 제외하고, s-maxage는 공유 캐시의 신선도를 정합니다.[1][3]
- 4 · 검증
정상 요청 하나가 아니라 응답 행렬을 시험합니다
캐시는 성공 페이지뿐 아니라 redirect와 404 같은 부정 응답도 저장할 수 있습니다. 사용자 상태, 언어, query와 오류 조건에서 반복 요청을 실행하고 purge·복구까지 시험해야 합니다.[1]
첫 질문은 누가 같은 bytes를 공유해도 되는가입니다
팀은 측정하기 쉬운 TTL부터 정하는 경우가 많습니다. 하지만 그것은 두 번째 결정입니다. 먼저 두 요청이 같은 표현을 받아도 되는지 판단해야 합니다. 공개 문서는 여러 사용자가 공유해도 되지만 계정 페이지, 초안 미리보기나 session별 token이 들어간 응답은 대개 그렇지 않습니다.[1][2][3]
Cookie가 있다는 사실만으로 응답이 private가 되지는 않습니다. 인증·개인화 콘텐츠를 브라우저에 저장해도 된다면 private를 명시하고, 아예 저장하지 않아야 하면 no-store를 사용하세요. 우연히 포함된 헤더를 보고 CDN 규칙이 개인정보 경계를 추측하게 두지 않습니다.[1][2][3]
캐시 키는 애플리케이션 정확성의 일부입니다
대부분의 캐시는 method와 URL로 시작합니다. URL 하나가 재사용 가능한 표현 하나를 뜻할 때만 충분합니다. 언어, 허용 encoding 또는 다른 요청 헤더에 따라 응답이 바뀐다면 키도 그 입력을 반영해야 합니다. Vary는 헤더 기반 변형을 선언하는 HTTP 방식입니다.[1][4]
Vary를 명확한 URL이나 개인정보 규칙 대신 사용하지 마세요. Vary: User-Agent는 재사용률이 낮은 수많은 변형을 만들고, Vary: Cookie는 키 공간을 크게 늘리면서 어떤 cookie가 중요한지도 설명하지 못합니다. Locale 경로, version이 붙은 asset과 private 응답이 보통 더 운영하기 쉽습니다.[1][4]
no-cache는 저장 금지가 아닙니다
이름 때문에 비용이 큰 실수가 생깁니다. no-cache는 응답 저장을 허용하지만 재사용 전에 검증하게 합니다. no-store는 저장하지 말라는 뜻입니다. private는 사용자 cache에는 저장할 수 있지만 shared cache에는 두지 않습니다. s-maxage는 브라우저의 max-age와 별도로 shared cache의 신선도를 정합니다.[2][3]
Hash가 붙은 JavaScript, CSS와 이미지는 내용이 바뀌면 새 URL이 생기므로 긴 수명이 적합합니다. 공개 HTML은 보통 ETag나 Last-Modified로 검증하는 편이 낫습니다. 개인화 페이지는 성능 조정 전에 private 또는 no-store 정책이 필요합니다.[2][3]
다음 요청을 오염시킬 수 있는 상태를 시험하세요
익명 사용자의 성공 요청 하나로는 충분하지 않습니다. 같은 URL을 로그인 전후, 지원 locale, query 변형과 origin 오류 뒤에 반복 요청하세요. Body와 status code뿐 아니라 Age, Cache-Control, Vary, validator와 CDN cache-status 헤더를 함께 확인합니다.[1][2]
복구도 release 시험에 포함하세요. 정확한 키를 purge하고 다음 요청이 의도한 origin 경로에 도달하는지, 404나 redirect가 canonical 페이지의 identity 아래 저장될 수 없는지 확인합니다. 목표는 빠른 첫 시연이 아니라 평범한 실패 상황에서도 예측 가능한 재사용입니다.[1][2]
- Public, private, 저장 금지 응답 분류
- 공유 응답마다 완전한 cache key 정의
- 익명·인증 요청을 분리해 확인
- Locale, query, redirect와 404 변형 검사
- 대상 purge와 origin 복구 실행