HTTP 캐시는 응답을 저장하는 기능 하나가 아니라 저장해도 되는가, 지금 재사용해도 되는가, 누구와 공유할 수 있는가를 함께 판단하는 계층입니다. 이 노트는 조건부 요청과 표현 협상, 사용자 전환, validator, Vary를 실제 cache hit 경로와 연결합니다.
저장 허용·재사용 검증·공유 범위
캐시 의사결정을 저장 가능성 → 신선성 또는 재검증 → 현재 요청의 사용자·표현과 키 일치로 나누면 no-cache와 no-store를 혼동하지 않게 됩니다. 개인 응답은 private이어도 같은 브라우저의 계정 전환 뒤 재사용될 수 있으므로 서버 인가가 실행되지 않는 hit 경로를 별도로 검토합니다.
개인 프로필 응답을 캐시하면 반복 조회를 줄일 수 있지만 다른 사용자에게 같은 본문을 주면 안 됩니다. 공개 상품 페이지도 언어·압축·형식이 다르면 같은 URL의 다른 표현일 수 있습니다. 캐시는 저장 허용, 재사용 전 검증, 공유 범위를 각각 정해야 합니다.
| 지시자 | 핵심 의미 | 하지 않는 일 |
|---|---|---|
| private | 공유 캐시 저장 제한, 개인 캐시 가능 | 같은 브라우저의 계정 전환 감지 |
| no-store | 저장하지 말라는 지시 | 이미 저장된 사본·스크린샷 삭제 |
| no-cache | 재사용 전 검증 필요 | 저장 자체 금지 |
| max-age | 신선하게 재사용할 수 있는 시간 | 권한 최신성·연결 수명 보장 |
민감 정보는 no-store를 우선 고려하고 앱 메모리·Service Worker·화면 복원 상태도 함께 관리합니다. HTTPS는 전송을 보호하지만 저장된 응답의 공유·재사용 정책을 대신하지 않습니다.
ETag와 표현 동일성 검증
A가 v7을 받아 캐시에 저장한 뒤 원본이 v8이 되면 A의 조건부 요청은 서버의 현재 인증·표현 선택 뒤 ETag 비교를 거쳐 200을 받아야 합니다. 반대로 인증이나 자원 인가가 실패하면 같은 ETag라는 이유로 304를 반환하지 않아야 하며, 304는 본문을 보내지 않는 재검증 성공이지 권한 토큰이 아닙니다.
서버가 본문과 ETag: "v7"을 보냈다면 클라이언트는 이후 If-None-Match: "v7"을 보낼 수 있습니다. 현재 선택된 표현과 일치하면 304를 반환해 기존 본문을 재사용하고 필요한 메타데이터를 갱신합니다. 바뀌었다면 200과 새 본문을 받습니다.
그림을 글로 읽기
- If-None-Match: v7
- 현재 요청 검사: 인증 · 자원 인가 · 표현 선택
- ETag 비교
- 일치: 304: 같은 캐시 본문 재사용
- 불일치: 200: 새 본문·태그
- If-None-Match: v7 → 현재 요청 검사: 조건부 GET
- 현재 요청 검사 → ETag 비교: 허용된 표현
- ETag 비교 → 일치: 304: 같음
- ETag 비교 → 불일치: 200: 변경됨
304는 본문 전송을 줄이지만 네트워크 왕복과 서버 검사는 남습니다. 태그는 불투명한 검증자이며 암호화·인증 토큰이 아닙니다. 개인정보를 태그에 직접 넣지 않습니다.
동일 브라우저의 사용자 전환과 캐시 격리
재현 순서는 A 로그인 → 프로필 cold 요청 → 로그아웃 → B 로그인 → 같은 URL 요청입니다. 예상 결과는 B가 A의 본문을 받지 않는 것이며, 이 테스트를 cold 요청만으로 수행하면 fresh private cache와 Service Worker·복원 상태의 누출을 놓칠 수 있습니다.
A가 프로필 URL의 fresh private 응답을 받은 뒤 로그아웃하고 B가 로그인했다고 합시다. 개인 캐시는 공유 CDN은 아니지만 같은 브라우저에 남을 수 있습니다. fresh 응답을 원본에 묻지 않고 재사용하면 A 본문이 다시 보일 수 있습니다.
서버 인가는 서버에 온 요청에만 적용됩니다. 원본 요청 자체가 생략되는 경로에서는 캐시 키·저장 금지·계정 전환 시 상태 정리가 중요합니다. 로그인 성공을 이전 캐시 삭제로 간주하지 않습니다. 테스트는 A가 캐시를 채운 뒤 B가 같은 URL을 요청하는 순서로 해야 합니다. 둘 다 cold 상태만 시험하면 혼합을 놓칩니다.
Accept·Content-Type의 요청·응답 방향
요청을 진단할 때 body의 형식은 Content-Type, 선호하는 응답 표현은 Accept, 실제 응답 표현은 응답 Content-Type으로 각각 기록합니다. JSON 요청에 HTML 응답이 올 수 있다는 사실을 전제로 415와 406을 서로 다른 실패 원인으로 분류해야 client 재시도와 서버 협상 오류를 분리할 수 있습니다.
요청 Content-Type: application/json은 보내는 본문의 형식이고 Accept: text/html은 받고 싶은 응답의 선호입니다. JSON을 보낸다고 JSON 응답을 요구한 것이 아닙니다. 서버는 지원하는 표현을 선택해 응답 Content-Type으로 실제 형식을 밝힙니다.
지원하지 않는 입력 미디어 유형의 415와 응답 협상 실패의 406은 다른 문제입니다. Accept의 복수 선호·q 값·생략 정책을 정하고 파싱한 데이터의 필드 의미·인가도 별도로 검증합니다. MIME이 맞다고 HTML 입력이 안전한 것은 아닙니다.
Vary의 표현 구분과 인가 한계
Vary는 응답 표현을 바꾸는 요청 조건을 캐시 키에 반영하는 장치이지 사용자 권한을 대신하는 장치가 아닙니다. 언어·압축·미디어 타입이 달라지는 공개 응답에는 유용하지만, 개인 API를 쿠키 전체로 공유하는 설계는 키 폭증과 권한 변화 문제를 남기므로 공개 셸과 개인 데이터 분리를 먼저 비교합니다.
Accept-Language로 언어가 바뀌면 캐시가 그 요청 헤더를 표현 선택에 사용하도록 Vary를 설정할 수 있습니다. 압축·미디어 타입·Origin 등 실제로 응답을 바꾸는 조건도 캐시 키와 일치해야 합니다. CDN의 강제 캐시 규칙이 원본 헤더를 무시하는지도 확인합니다.
Vary:Cookie를 넣었다고 모든 개인정보 응답을 안전하게 공유할 수 있는 것은 아닙니다. 쿠키 값의 변화로 키가 폭증할 수 있고, 권한 변화·인증 응답의 저장 조건은 별도입니다. 공개 HTML 셸과 개인 API를 분리하는 대안도 있습니다.
Strong·weak validator 비교 규칙
강한 ETag는 바이트 표현의 동일성에 맞는 검증자입니다. W/"v7"처럼 약한 태그는 의미상 동등한 표현의 재검증에 쓸 수 있지만 바이트 조각을 이어 붙이거나 If-Match의 강한 비교를 대신하지 못합니다. gzip 등 인코딩별 바이트가 다르면 강한 검증자도 그 표현에 맞게 제공해야 합니다.
| 용도 | 확인할 계약 |
|---|---|
| GET 재검증, If-None-Match | 약한 비교 사용 가능 |
| 변경 전제, If-Match | 강한 비교 |
| 부분 다운로드, If-Range | 강한 validator 등 허용 조건 필요 |
태그 문자열만 비교하는 앱 구현은 실제 HTTP 비교 규칙을 놓칠 수 있습니다. 사용 중인 서버·캐시 라이브러리의 조건부 요청 처리를 확인합니다.
캐시 hit와 안전한 결과의 독립 검증
테스트 결과에는 본문뿐 아니라 hit/miss, Age, Vary, ETag, 인증 상태, Service Worker 경로를 남깁니다. 동일 URL을 사용자·언어·압축 조건으로 순차 요청하고 cold와 warm을 나누어 비교해야 표현 혼합과 개인 데이터 재사용을 실제로 진단할 수 있습니다.
사용자·언어·압축·Accept를 바꿔 같은 URL을 순서대로 요청하고 응답 본문과 cache status·Vary·validator를 대조합니다. 로그아웃·권한 회수·원본 장애·304·Service Worker 응답도 따로 시험합니다. hit 비율이 올랐다는 이유로 표현 혼합이나 잘못된 개인 데이터 보존을 정당화하지 않습니다.