llm-wiki/raw/official-docs/rfc9111-http-caching.md

title, source_type, url, archive_url, vendor, related_branches, related_projects, tags, status, confidence, created, last_reviewed

title	source_type	url	archive_url	vendor	related_branches	related_projects	tags	status	confidence	created	last_reviewed
official-doc / RFC 9111 — HTTP Caching	official-doc	https://www.rfc-editor.org/rfc/rfc9111		IETF	feature-api-contract-baseline	ca-skeleton	official-doc ca-skeleton api-design http caching	raw	high	2026-05-31	2026-05-31

official-doc / RFC 9111 — HTTP Caching

Layer: raw/official-docs/ — 외부 공식 자료의 원문 발췌·출처 기록. 검증된 요약은 /ingest 후 wiki/concepts/ 에 source-summary-template 형식으로 별도 작성. 원본은 raw 에 영구 보관.

Parent / 활용 branch

이 자료는 혼자 존재하지 않는다. 어느 branch 의 구현 결정의 근거로서 보관됨.

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-api-contract-baseline	D16: 응답 cache 정책 default = Cache-Control: no-store (인증된 API 안전 default) · cacheable endpoint 만 controller annotation 으로 private, max-age=N opt-in. RFC 9111 §5.2 가 normative 근거.

출처 / Source

• 원본 URL: https://www.rfc-editor.org/rfc/rfc9111
• 아카이브 URL: (미기입)
• 저자 / 조직: Roy T. Fielding (Adobe), Mark Nottingham (Fastly), Julian Reschke (greenbytes) — IETF
• 발행일: June 2022
• 마지막 확인일: 2026-05-31
• 표준 트랙: STD 98 (Internet Standards Track), Obsoletes RFC 7234

왜 저장했는지 / Why archived

feature-api-contract-baseline D16 결정 — 인증된 API 의 응답 cache 정책 default 를 Cache-Control: no-store 로 고정하고 cacheable endpoint 만 annotation opt-in 하는 결정의 normative 근거. RFC 9111 §3 (저장 조건) 와 §5.2.2 (Cache-Control response directives — no-store, private, public, max-age) 가 각 directive 의 의미론을 정의한다. no-store 가 "인증된 API 의 안전한 default" 라는 권고 자체는 표준 밖(project-internal trade-off)이나, 각 directive 의 normative 정의는 본 RFC 가 단일 근거.

핵심 인용 / Key quotes (verbatim)

[§3] "A cache MUST NOT store a response to a request unless:" [이어서 no-store 부재, private/public directive 존재 등 조건 열거] — 핵심: no-store cache directive 가 response 에 있으면 저장 자체가 금지됨.

(full condition list excerpt, §3, line 284–327): "A cache MUST NOT store a response to a request unless: [...] the no-store cache directive is not present in the response (see Section 5.2.2.5); [...] if the cache is shared: the private response directive is either not present or allows a shared cache to store a modified response;"

[§5.2] "The "Cache-Control" header field is used to list directives for caches along the request/response chain. Cache directives are unidirectional, in that the presence of a directive in a request does not imply that the same directive is present or copied in the response."

[§5.2.2.5] "The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or the response and MUST NOT use the response to satisfy any other request."

[§5.2.2.7] "The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user). It also indicates that a private cache MAY store the response, subject to the constraints defined in Section 3, even if the response would not otherwise be heuristically cacheable by a private cache."

[§5.2.2.9] "The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable. For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (Section 3.5)."

[§5.2.2.1] "The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리한다.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
RFC9111-C1	no-store cache directive 가 response 에 있으면 cache 는 해당 request 와 response 의 어떤 부분도 저장해서는 안 된다	[§5.2.2.5] "The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or the response and MUST NOT use the response to satisfy any other request."	official-standard	HTTP/1.1 이상 캐시 구현체 전반 (shared + private cache 모두 적용)	no-store 가 모든 인증 API 의 "안전한 default" 라는 권고 — 그것은 project-internal trade-off. 표준은 semantic 만 정의. no-store 가 실제로 모든 캐시에서 존중됨을 보장하지 않음 ("not a reliable or sufficient mechanism for ensuring privacy")
RFC9111-C2	private directive 는 shared cache 가 response 를 저장하는 것을 금지하고, single user 전용임을 의미한다	[§5.2.2.7] "The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user)."	official-standard	shared cache (CDN, proxy 등) 와 private cache (브라우저) 구분이 필요한 모든 HTTP 응답	private directive 가 메시지 내용 자체의 privacy 를 보장한다는 의미가 아님 ("only controls where the response can be stored; it cannot ensure the privacy of the message content")
RFC9111-C3	public directive 는 Authorization 헤더가 있어도 shared cache 에 저장 허용하는 명시적 마킹이다	[§5.2.2.9] "The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable."	official-standard	Authorization header 가 포함된 요청의 응답을 shared cache 에 저장해야 하는 경우	인증된 API 에 public 을 사용하는 것이 안전하다는 보장 없음 — 단지 "가능하다" 는 허용일 뿐. CDN/proxy 의 실제 동작은 각 vendor implementation 에 달림
RFC9111-C4	max-age response directive 는 지정된 초 수 이후 response 가 stale 로 간주됨을 의미한다	[§5.2.2.1] "The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds."	official-standard	명시적 freshness lifetime 을 설정하는 모든 캐시 가능 응답	max-age 설정만으로 캐시 가능성이 보장되지 않음 — §3 의 저장 조건 (no-store 부재, public/private 등) 을 동시에 만족해야 함
RFC9111-C5	Cache-Control 헤더 필드는 request/response chain 의 캐시를 위한 directive 목록이며, directive 는 단방향(unidirectional)이다	[§5.2] "The "Cache-Control" header field is used to list directives for caches along the request/response chain. Cache directives are unidirectional, in that the presence of a directive in a request does not imply that the same directive is present or copied in the response."	official-standard	HTTP 캐시 구현체 전반	특정 Spring @CacheControl 어노테이션 또는 프레임워크 동작 방식 — 그것은 vendor 구현 사항. RFC 는 의미론만 정의
RFC9111-C6	§3 의 저장 조건에서 no-store directive 가 response 에 있으면 cache 는 저장하지 않아야 하며, private directive 가 있으면 shared cache 는 저장 불가	[§3] "the no-store cache directive is not present in the response (see Section 5.2.2.5); [...] if the cache is shared: the private response directive is either not present or allows a shared cache to store a modified response"	official-standard	어떤 응답이 cacheable 인지 판단하는 모든 캐시 구현체	no-store 와 private 의 조합 동작 — 표준은 각각의 조건을 열거하며, 두 directive 를 동시에 사용하는 경우의 behavior 에 대한 별도 normative 진술은 없음

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:

  • RFC9111-C1: no-store response directive 의 normative 의미 — "저장하지 말 것"의 MUST NOT 의무
  • RFC9111-C2: private directive 의 normative 의미 — shared cache 저장 금지, single user 전용
  • RFC9111-C3: public directive 의 normative 의미 — 명시적 캐시 허용 (Authorization 헤더 포함 응답에도)
  • RFC9111-C4: max-age response directive 의 normative 의미 — stale 판정 기준 초 수
  • RFC9111-C5: Cache-Control 헤더 필드 자체의 역할과 unidirectional 특성
  • RFC9111-C6: §3 저장 조건에서 no-store / private directive 존재 시의 저장 금지 조건

• 이 자료가 증명하지 않는 것:

  • no-store 가 모든 인증 API 의 "안전한 default" 라는 권고 — 이는 project-internal trade-off. RFC 는 의미론만 정의하며 어떤 값을 default 로 권고하지 않는다.
  • Spring Boot / Spring MVC 의 @CacheControl 어노테이션 또는 HttpCacheControl 동작 방식 — vendor implementation 사항.
  • no-store 가 실제로 모든 캐시(악성 캐시 포함)에서 항상 존중됨 — RFC 본문이 명시적으로 "not a reliable or sufficient mechanism for ensuring privacy" 라고 언급.
  • Vary 헤더의 normative 정의 — 그것은 RFC 9110 §12.5.5 의 영역. 본 RFC 는 Vary 와 캐시 키 계산의 상호작용을 §4.1 에서 참조하나 Vary 자체 정의는 RFC 9110 이 SSOT.
  • CDN 또는 reverse proxy 의 실제 Cache-Control 처리 동작 — vendor 별 구현 사항.

• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:

  • feature-api-contract-baseline D16 결정의 Spring MVC CacheControl 설정 방식 (예: CacheControl.noStore() 또는 응답 헤더 직접 설정) — Spring 공식 문서 또는 wiki-source-summarizer 별도 dispatch 필요.
  • annotation opt-in 방식 (@ResponseHeader 또는 WebMvcConfigurer addResourceHandlers 또는 ResponseEntity builder) 의 ca-skeleton 적용 형태 — feature-cache-consistency-contract branch 와의 인터페이스 확인.
  • Vary: Accept, Accept-Encoding, Authorization 의무 근거는 RFC 9110 §12.5.5 별도 발췌 필요 — 현재 raw/official-docs/rfc9110-http-semantics.md 의 RFC9110-C18 예정 작업.

메모 / Notes

• RFC 9111 은 2022년 6월 발행, RFC 7234 (2014) 를 obsolete. STD 98 — Internet Standards Track.
• no-store 의 "MUST NOT store" 는 volatile storage 에서도 "best-effort attempt to remove" 를 포함 (§5.2.2.5 + §5.2.1.5). 단 표준은 "best-effort" 라 완전한 삭제 보장은 아님.
• D16 의 no-store default 는 RFC 가 권고한 것이 아님 — project-internal 안전 trade-off. 면접에서 "RFC 9111 이 no-store 를 default 로 쓰라고 한다" 는 표현은 부정확. 정확한 표현: "RFC 9111 이 no-store 의 의미를 normatively 정의하며, 인증된 API 에 대한 안전한 default 로 채택했다."
• no-cache (§5.2.2.4) 는 no-store 와 다름 — no-cache 는 저장은 허용하되 reuse 전 revalidation 의무. 혼동 금지.
• 추가 발췌 후보: §7.3 Caching of Sensitive Information — 민감 정보 캐싱 보안 고려사항.

Related / 관련

• raw/official-docs/rfc9110-http-semantics — RFC 9111 과 함께 HTTP 의미론 정의. §12.5.5 Vary 헤더 normative 정의 포함. D16 의 Vary 의무 근거.
• raw/branch-notes/feature-api-contract-baseline — D16 결정 (cache policy default) 의 decision branch.
• raw/branch-notes/feature-cache-consistency-contract — cache layer 구현 (Redis / in-memory) 의 owner branch. 본 raw 는 HTTP header 정책 근거만.
• 추가 참고 후보: RFC 7234 (obsoleted by this RFC), RFC 8246 (HTTP Immutable Responses).