HTTP 캐시 그룹

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 반영하고 있습니다. 공개 검토를 받았으며 인터넷 엔지니어링 지명 그룹(IESG)이 출판을 승인하였습니다. 인터넷 표준에 대한 추가 정보는 RFC 7841 2절에서 확인할 수 있습니다.

이 문서의 현재 상태, 정오표, 그리고 피드백 방법 등은 https://www.rfc-editor.org/info/rfc9875에서 확인할 수 있습니다.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

HTTP 캐싱 [HTTP-CACHING]은 단일 리소스 단위로 동작합니다. 하나의 저장된 응답의 신선도는 다른 응답에 영향을 주지 않습니다. 이러한 세분화는 여러 자산이 서로 다른 캐싱 요구 사항을 가지는 페이지 등에서 캐싱 효율을 높일 수 있습니다.

하지만 저장된 응답들 사이의 관계를 활용하면 캐시 효율성을 높일 수 있는 경우도 있습니다.

예를 들어, 관련된 리소스 집합을 무효화해야 하는 경우가 종종 있습니다. 이는 상태를 변경하는 요청이 다른 리소스에 부수 효과를 미치기 때문일 수도 있고, 단순히 관리적 편의를 위해서일 수도 있습니다(예: "사이트의 이 부분 무효화"). 응답을 그룹으로 묶으면 URL 구조 등에 의존하지 않고 이러한 관계를 명확하게 표현할 수 있습니다.

무효화 이벤트 공유 외에도, 그룹화로 표시된 관계를 통해 캐시는 자체 동작을 최적화할 수도 있습니다(예: 캐시 제거 알고리즘 작동에 참고 등).

2절에서는 HTTP 캐시에 저장된 응답의 관계를 설명하기 위해, 해당 응답을 하나 이상의 그룹과 연관시켜 관계를 반영하는 방법을 소개합니다. 또한 캐시가 그 정보를 활용하여 그룹의 구성원에게 무효화 이벤트를 적용하는 방법도 설명합니다.

3절에서는 그러한 이벤트의 새로운 출처 하나, 즉 상태 변경 응답이 그룹 무효화를 유발할 수 있도록 하는 HTTP 응답 헤더 필드를 소개합니다.

이러한 메커니즘은 단일 캐시 내에서, 단일 오리진 서버에 연결된 저장된 응답들에 적용됩니다(2.1절 참조). 여러 캐시(예: 계층 또는 메시 구조) 간 상태 동기화나 서로 다른 오리진의 응답 연관은 다루지 않습니다.

Cache-Groups 응답 헤더 필드는 문자열 리스트( 3.1절 및 3.3.3절 및 [STRUCTURED-FIELDS] 참고)입니다. 리스트의 각 멤버는 해당 응답이 속하는 그룹을 식별하는 값입니다. 이 문자열들은 불투명하며, 서버 입장에서 의미를 가질 수 있으나 캐시는 구조나 내용에 대한 이해 없이 단지 그룹을 고유하게 식별하는 용도로만 사용합니다.

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"

멤버의 순서는 중요하지 않습니다. 인식되지 않은 파라미터들은 무시해야 합니다.

구현체는 필드 값에 최소 32개 그룹, 각 멤버에 최대 32자 이상을 MUST 지원해야 합니다. 단, HTTP 필드 길이에 대한 일반적인 제한 때문에 실무에서 이 필드 값의 크기에 제약이 있을 수 있습니다.

Cache-Group-Invalidation 응답 헤더 필드는 문자열 리스트( 3.1절, 3.3.3절 및 [STRUCTURED-FIELDS] 참고)입니다. 리스트의 각 멤버는 해당 응답이 무효화하는 그룹을 식별합니다( 2.2.1절 참고).

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"

Cache-Group-Invalidation 헤더 필드는 안전한 메서드(e.g., GET, 9.2.1절, [HTTP] 참고) 요청 응답에서는 반드시 무시되어야 합니다.

캐시는 비안전 요청에 대한 응답에서 Cache-Group-Invalidation 헤더를 받으면, 리스트 내의 어떤 그룹과 공유하는 그룹이 있는 저장된 응답들을 무효화할 수 있습니다(MAY)( 2.1절 참고).

캐시 확장 기능은 위 요구사항을 명시적으로 강화할 수 있습니다. 예를 들어, 타겟 캐시 제어 헤더 필드 [TARGETED]는 캐시가 Cache-Group-Invalidation 신호를 반드시(필수) 준수하도록 명시할 수 있습니다.

멤버의 순서는 중요하지 않습니다. 인식되지 않은 파라미터들은 무시해야 합니다.

구현체는 필드 값에 최소 32개 그룹, 각 멤버에 최대 32자 이상을 MUST 지원해야 합니다. 단, HTTP 필드 길이에 대한 일반적인 제한 때문에 실무에서 이 필드 값의 크기에 제약이 있을 수 있습니다.

필드 이름:

Cache-Groups

상태:

permanent

참고:

RFC 9875

필드 이름:

Cache-Group-Invalidation

상태:

permanent

참고:

RFC 9875

이 메커니즘은 동일 오리진을 공유하는 리소스가 서로 무효화될 수 있도록 허용합니다. 이렇게 되면, 다수의 당사자가 관여하는 오리진(“공유 호스팅”이라 불림)에서는 한 당사자가 자신의 리소스를 타인의 리소스와 그룹으로 묶거나, 그들에게 부수 효과가 있는 신호를 보낼 수 있습니다.

이러한 위험을 줄이고자 하는 공유 호스트는 이 명세에서 정의된 헤더 필드 접근을 제어할 수 있습니다.

Stephen Ludin에게 검토 및 제안에 감사드립니다.