Summary#
304는 URI에 저장된 모든 응답을 갱신하라는 신호가 아니다. 캐시는 먼저 해당 요청에 사용할 수 있었던 저장 응답을 추리고, 304의 검증자로 갱신 대상을 식별한 뒤, 식별된 응답에만 304 메타데이터를 반영해야 한다. Vary에 따른 표현 선택과 검증자 식별을 혼동하면 다른 표현의 본문을 반환하거나 오래된 응답을 새로 검증된 것처럼 취급할 수 있다. (rfc-editor.org)
Key Points#
- 후보 선정: RFC 9111 §4.3.4의 초기 후보는 해당 요청에 대해 선택될 수 있었던 저장 응답이다. 이때 신선도 관련 마지막 요건만 제외한다.
Vary가 지정한 요청 헤더가 원래 저장을 유발한 요청과 맞지 않는 응답은 이 단계를 무시하고 304의 갱신 대상으로 삼아서는 안 된다. 캐시가 자체적으로 재검증 요청을 만들 때도 저장 응답의Vary지정 요청 헤더를 복사한다. (rfc-editor.org) - 검증자로 대상 확정: 304에 강한 검증자가 있으면 초기 후보 중 동일한 강한 검증자를 가진 응답 모두를 갱신한다. 일치 후보가 없으면 어느 저장 응답도 그 304로 갱신해서는 안 된다. 강한 검증자 없이 약한 검증자만 있고 일치 후보가 있으면 그중 가장 최근 응답을 갱신한다. 검증자가 전혀 없을 때는 초기 후보가 유일하고 그 후보에도 검증자가 없는 경우에만 갱신 대상으로 식별한다. (rfc-editor.org)
- 메타데이터 갱신: 식별된 각 응답에는 304가 제공한 헤더를 RFC 9111 §3.2에 따라 추가하거나 기존 값을 대체한다. 이는 본문 교체가 아니다. 저장 예외에 해당하는 필드, 저장 응답이 의존하는 필드, 수신 과정에서 자동 처리·제거되는 필드,
Content-Length는 일반적인 갱신 대상에서 제외된다. (rfc-editor.org) - 표현별 불일치 실패 모드: 예컨대 한 URI의
Vary: Accept-Language아래 영어·한국어 응답이 별도로 저장되어 있는데, 구현이 URI만으로 304를 연결하거나 다른 표현의 ETag를 현재 표현의 검증 결과로 간주하면 잘못된 본문을 반환할 수 있다.If-None-Match는 서버가 선택한 표현의 태그와 비교하며, 그 비교에는 약한 비교를 사용한다. 따라서 요청의 표현 선택과 캐시의 304 갱신 대상 식별은 별도로 정확히 수행해야 한다. 이는 규정에서 도출한 실패 시나리오이지, 특정 제품에서 확인된 결함은 아니다. (rfc-editor.org)
Cautions#
If-None-Match의 약한 비교 규칙을 304 수신 후 저장 응답 식별 규칙과 동일시하면 안 된다. 후자는 RFC 9111 §4.3.4의 후보 집합 및 강·약 검증자별 순서를 따른다. (rfc-editor.org)- 위 실패 시나리오의 발생 빈도, 실제 영향 범위, 특정 캐시 구현의 동작은 조사한 RFC만으로 확인되지 않았다.
- 304는 본문을 담지 않는다. 갱신 대상으로 식별할 저장 응답이 없는데도 304만으로 본문을 구성할 수 있다고 가정해서는 안 된다. (rfc-editor.org)
Sources#
- RFC 9111 — HTTP Caching, §§3.2, 4.1, 4.3.1, 4.3.4 (rfc-editor.org)
- RFC 9110 — HTTP Semantics, §§13.1.2, 15.4.5 (rfc-editor.org)
Sagwan Revalidation 2026-10-20T09:52:40Z#
- verdict:
ok - note: RFC 9110·9111의 재검증 규칙과 부합하며, 갱신이 필요한 오류는 보이지 않는다.