HTTP 변경 불가능(Immutable) 응답

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

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

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

Copyright (c) 2017 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

HTTP의 신선도 수명 메커니즘 [RFC7234]은 클라이언트가 지정된 기간 동안 저장된 응답을 안전하게 재사용하여 향후 요청을 처리할 수 있게 해줍니다. 하지만 그 기간 동안 리소스가 수정될 가능성은 여전히 존재합니다.

예를 들어, 일간 신문 첫 페이지의 사진에 1시간의 신선도 수명이 부여되면, 어느 사용자도 1시간 이상 된 캐시된 사진을 보지 않게 됩니다. 하지만 사진은 언제든지 변경될 수 있으므로, 서로 다른 사용자가 최대 1시간 동안 각자 캐시에 저장된 다른 사진을 볼 수 있습니다. 이는 [RFC7234]에 정의된 캐싱 메커니즘을 준수합니다.

캐시된 응답에 대한 변경 여부를 확인해야 하는 사용자는 일반적으로 사용자 에이전트에서 새로고침(리로드) 기능을 사용합니다. 이는 조건부 요청 [RFC7232]을 발생시키며, 리소스가 변경되었을 경우 새 표현(Representation)이, 변경되지 않았을 경우 304 (Not Modified) 응답 [RFC7232]이 반환됩니다. HTML을 이해하고 종속 하위 리소스를 불러오는 사용자 에이전트는 한 페이지의 모든 부분을 새로고침하기 위해 수백 개의 조건부 요청을 발생시킬 수 있습니다 [REQPERPAGE].

하지만 일부 콘텐츠 제공자는 "버전이 명시된" URL을 사용하기 때문에 하위 리소스의 변형을 한 개만 생성합니다. 이러한 리소스가 업데이트될 때는, 단순히 새로운 URL에 해당 리소스를 게시하며, 일반적으로 경로에 해당 버전만의 고유 식별자를 포함시킵니다. 하위 리소스에 대한 참조도 새로운 경로 정보로 갱신됩니다.

예를 들어, https://www.example.com/101016/main.css가 업데이트되어 https://www.example.com/102026/main.css로 재게시될 수 있으며, 이를 참조하는 링크도 동시에 변경됩니다. 이 설계 패턴을 통해 하위 리소스에 대해 매우 긴 신선도 수명을 부여할 수 있으며, 언제 업데이트될지 예측할 필요가 없습니다.

안타깝게도 사용자 에이전트는 이러한 버전 관리 URL 설계 패턴이 사용되는지 알지 못합니다. 결과적으로 사용자가 새로고침을 시도하면 각 하위 리소스마다 쓸모없는 조건부 요청이 발생하며, 이는 모두 304 응답을 반환하게 됩니다.

immutable HTTP 응답 Cache-Control 확장은 서버가 신선도 수명 동안 업데이트되지 않을 응답을 식별할 수 있게 해줍니다.

이 확장은 해당 응답에 대해 조건부 요청을 생략해도 업데이트 여부를 걱정할 필요가 없음을 클라이언트에 명확히 알려줍니다.

HTTP 응답에 immutable Cache-Control 확장이 포함되어 있으면, 원본 서버가 해당 응답의 신선도 수명 동안 해당 리소스의 표현(Representation)을 변경하지 않음을 나타냅니다.

클라이언트는 응답의 신선도 수명 동안(예: 새로고침 시) 명시적으로 사용자가 강제 새로고침을 하지 않는 한 조건부 요청을 발행하지 않아야 합니다.

immutable 확장은 저장된 응답의 신선도 수명 동안에만 적용됩니다. 만료된(stale) 응답은 immutable 확장이 없는 경우와 동일하게 재검증되어야 합니다.

immutable 확장은 인자를 갖지 않습니다. 인자가 있을 경우 의미가 없으며 무시되어야 합니다. immutable 확장이 여러 번 등장해도 한 번 등장한 것과 동일하게 간주합니다. 요청에서 immutable Cache-Control 확장이 사용되어도 아무런 효과가 없습니다.

• 클라이언트는 HTTPS와 같은 인증된 컨텍스트에 속하지 않은 리소스의 immutable 확장은 무시해야 합니다. 인증된 리소스는 캐시 오염에 덜 취약합니다.
• 사용자 에이전트는 보통 리로드와 강제 리로드 두 가지 새로고침 메커니즘을 제공합니다. 강제 리로드는 중단된 로드나 기타 오염을 바로잡기 위해 사용됩니다. 이 리로드(보통 no-cache 요청 속성으로 표시)는 immutable 확장 역시 무시해야 합니다.
• 클라이언트는 저장된 응답 크기가 올바른지 강하게 보장하지 않는 리소스(연결 종료로 구분되는 응답 등)에 대해서는 immutable 확장을 무시해야 합니다.

immutable 확장은 7.1절 [RFC7234]에 설명된 가이드라인에 따라 “Hypertext Transfer Protocol (HTTP) Cache Directive Registry”에 등록되었습니다.

• 캐시 지시어: immutable
• 참고: RFC 8246

이 아이디어의 개발과 테스트에 협력해준 Ben Maurer에게 감사드립니다. 프록시 상호작용에 도움을 준 Amos Jeffries와 문서화에 도움을 준 Mark Nottingham에게도 감사드립니다.