Cache-Status HTTP 응답 헤더 필드

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

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

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

Copyright (c) 2022 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 응답 헤더 필드 "Cache-Status"를 정의합니다.

Cache-Status HTTP 응답 헤더 필드는 캐시가 해당 응답과 관련 요청을 어떻게 처리했는지를 나타냅니다. 이 헤더 필드의 문법은 STRUCTURED-FIELDS를 따릅니다.

값은 List입니다. List의 각 항목은 요청을 처리한 캐시를 나타냅니다. 첫 번째 항목은 오리진 서버에 가장 가까운 캐시를, 마지막 항목은 사용자에 가장 가까운 캐시(사용자 에이전트의 캐시가 값을 추가한 경우 해당 캐시 포함)를 나타냅니다.

캐시는 언제 Cache-Status 헤더 필드를 응답에 추가할지 자체적으로 결정합니다. 어떤 캐시는 모든 응답에 추가할 수 있고, 다른 캐시는 특정 구성일 때나 요청에 디버그 모드를 활성화하는 헤더가 포함된 경우에만 추가할 수 있습니다. 관련 보안 고려사항은 Section 6을 참조하십시오.

중개자는 자신이 로컬에서 생성한 응답(예: 잘못된 요청으로 생성된 400 응답)에는 Cache-Status 멤버를 추가해서는 안됩니다. 단, 생성된 응답이 저장된 응답을 기반으로 하는 경우(예: 304 또는 206과 같이 저장된 응답을 기반으로 하는 경우)는 예외입니다. 예를 들어 프록시가 잘못된 요청으로 400 응답을 생성했다면, 이는 오리진이 아닌 프록시가 생성한 응답이므로 Cache-Status 값을 추가하지 않습니다.

캐시가 Cache-Status 헤더 필드에 값을 추가할 때는 기존 필드 값을 보존해야 하며, 이를 통해 요청을 처리한 전체 캐시 체인을 디버깅할 수 있습니다.

각 List 항목은 해당 항목을 삽입한 캐시를 식별하며, 이 식별자는 String 또는 Token이어야 합니다. 배포 환경에 따라 제품명 또는 서비스명(예: "ExampleCache" 또는 "Example CDN"), 호스트명("cache-3.example.com"), IP 주소 또는 생성된 문자열일 수 있습니다.

List의 각 항목은 해당 캐시의 요청 처리 방식을 설명하는 파라미터를 가질 수 있습니다. 이러한 파라미터는 선택 사항이지만, 캐시는 가능한 한 많은 정보를 제공하는 것이 권장됩니다.

이 명세서는 다음과 같은 파라미터들을 정의합니다.

Cache-Status: ExampleCache; hit

Cache-Status: ExampleCache; hit; ttl=376

Cache-Status: ExampleCache; hit; ttl=-412

Cache-Status: ExampleCache; fwd=uri-miss

Cache-Status: ExampleCache; fwd=stale; fwd-status=304

Cache-Status: ExampleCache; fwd=uri-miss; collapsed

Cache-Status: ExampleCache; fwd=uri-miss; collapsed=?0

Cache-Status: OriginCache; hit; ttl=1100,
              "CDN Company Here"; hit; ttl=545

Cache-Status: ReverseProxyCache; hit
Cache-Status: ForwardProxyCache; fwd=uri-miss; collapsed; stored
Cache-Status: BrowserCache; fwd=uri-miss

새로운 Cache-Status 파라미터는 "HTTP Cache-Status" 레지스트리에 등록하여 정의할 수 있습니다.

등록 요청은 지정된 전문가가 검토하고 승인합니다(관련: RFC8126, Section 4.5). 명세 문서는 권장되지만 필수는 아닙니다.

• 커뮤니티 피드백
• 값이 충분히 잘 정의되어 있는지 여부
• 일반적인 파라미터가 벤더 특정, 애플리케이션 특정 또는 배포 특정 값보다 선호됩니다. 커뮤니티에서 일반 값을 합의할 수 없다면, 파라미터 이름은 벤더나 애플리케이션 또는 배포를 식별하는 접두사를 포함하는 등 그에 맞게 구체적이어야 합니다.

Name:

[Cache-Status 파라미터 키의 이름; 구문 요구사항은 Section 3.1.2(STRUCTURED-FIELDS) 참조]

Type:

[파라미터 값의 Structured Type; Section 3.1.2 참조]

Description:

[파라미터의 의미에 대한 설명]

Reference:

[해당 파라미터를 정의하는 명세에 대한 참조(가능한 경우)]

등록 요청을 보낼 위치에 대한 세부사항은 레지스트리(<https://www.iana.org/assignments/http-cache-status>)를 참조하십시오.

IANA는 <https://www.iana.org/assignments/http-cache-status>에 "HTTP Cache-Status" 레지스트리를 생성하고, 섹션 2에 정의된 타입들로 이를 채웠습니다. 관련 절차는 섹션 4를 참조하십시오.

Field name:

Cache-Status

Status:

permanent

Reference:

RFC 9211

공격자는 Cache-Status에 포함된 정보를 사용해 캐시(및 기타 구성 요소)의 동작을 탐색하고, 캐시를 이용하는 이들의 활동을 추론할 수 있습니다. Cache-Status 헤더 필드 자체만으로 이러한 위험을 만들지는 않더라도, 공격자가 이를 악용하는 데 도움을 줄 수 있습니다.

예를 들어, 캐시가 응답을 저장했는지 여부를 알면 민감한 데이터에 대한 타이밍 공격을 수행하는 데 도움이 될 수 있습니다.

또한 캐시 키를 노출하면 공격자가 캐시 키의 변경을 이해하는 데 도움이 되어 캐시 포이즈닝 공격을 도울 수 있습니다. 자세한 내용은 ENTANGLE을 참조하십시오.

기본 위험은 암호화 및 인증 사용, 공격자가 제어하는 데이터를 캐시 키에 포함하지 않음 등 다양한 기법으로 완화할 수 있습니다. 단순한 키의 난독화는 이 위험을 완화하지 못합니다.

이러한 공격을 돕지 않기 위해 Cache-Status 헤더 필드는 생략하거나, 클라이언트가 수신 권한이 있을 때에만 전송하거나, 민감한 정보(예: key 파라미터)는 클라이언트가 권한이 있을 때에만 전송할 수 있습니다.