RFC-9111 HTTP Caching 무엇이 바뀌었나?
AWS CloudFront는 CDN 서비스이고 Cache를 해주고 있다고 대부분 이해 하고 있을 것 입니다.
CDN 서비스의 가장 핵심이 되는 HTTP Caching에 대한 구현도 중요하며 모던브라우저들에서는 CDN으로 부터 받는 응답 또한 RFC에 등록되어 있는 HTTP Protocol에 관련된 모든 표준에 따라 처리되게 구현되어야 합니다.
이렇게 보내는 쪽과 받는 쪽 모두 신뢰성 있는 컨텐츠를 요청하고 받을 수 있는 것은 합의된 HTTP Protocol을 따르고 있기 때문입니다.
아래 타임라인으로 보게 되면 2000년대에 들어서 HTTP Protocol의 업데이트가 이전보다 빨라지고 있습니다.
2000년대 부터 인터넷 사용자가 전세계적으로 급격하게 늘어남과 동시에 모바일기기의 발전이 가속화 되었습니다. 이로 인해 인터넷상의 사용자 트래픽은 이전보다 다양하고 복잡한 조건과 요구사항을 가지게 되었습니다.
특히 여러 위험으로부터 사용자의 보호를 위해 다양한 Draft 문서가 등록되고 있기 때문에 업데이트가 빨라지는 경향이 보입니다.
RFC (Request for comments)가 뭐에요?
IETF(Internet Engineering Task Force)는 1986년에 설립된 최고의 인터넷 표준 개발 조직(SDO)입니다. 이곳에서 기술 문서를 RFC로 게시하고 있습니다. RFC는 역사적 제목인 *Requests for Comments*의 약어입니다. RFC는 1969년에 게시된 RFC 1부터 시작하여 순차적으로 번호가 매겨집니다(RFC 시리즈는 IETF보다 앞서 있음). 각 RFC에는 일반적으로 ‘인터넷 표준’, ‘제안된 표준’, ‘정보용’, ‘실험용’ 또는 ‘역사적’ 중 하나의 상태가 있습니다. 일부 상태는 시간이 지남에 따라 변경될 수 있습니다. RFC는 자유롭게 사용할 수 있습니다.
다만 RFC가 게시되면 수정되지 않습니다. 설명하는 사양이 변경되면 표준은 첫 번째를 “구식화”하는 다른 RFC에 다시 게시됩니다. RFC에서 기술적 또는 편집상의 오류가 발견되면 정오표가 RFC에 연결되거나 다음 문서 업데이트를 위해 보류될 수 있습니다.
좀 더 자세히 설명이 잘 되어 있는 링크를 남겨 두겠습니다.
https://en.wikipedia.org/wiki/Request_for_Comments — Wikipedia Request for Comments
RFC(Request for Comments)란? RFC의 역사, RFC 종류, RFC 표준화 절차 — net-study.club
RFC(Request for Comments) 란? — lesstif.com
RFC-9111 HTTP Caching
이번에 살펴볼 RFC-9111은 기존 RFC-7234가 업데이트된 문서입니다.
2015년에 QUIC가 Draft가 되어 많은 관심을 받았고, HTTP 프로토콜에 관련된 제안 문서 중 HTTP Caching문서는 2016년 7월에 Draft되기 시작하여 수정 되어 왔습니다. 최종적으로 RFC-9111로 2022년 6월에 릴리즈 되었습니다.
기존 RF-7234 HTTP/1.1 Caching 문서에서 RFC-9111로 주요 변경된 세션은 7개로 이것에 대해 살펴 보겠습니다.
상세한 내용은 RFC-9111(링크)에서 보실수 있습니다.
1. Calculating Freshness Lifetime (Session 4.2.1) - updated
Handling of duplicate and conflicting cache directives has been clarified. (Section 4.2.1)
Cache된 객체에 대한 응답되는 헤더값 중 중복되거나 충돌되는 지시자에 대해서 좀 더 명확한 가이드가 업데이트 되었습니다.
가장 아래 마지막 구문과 같이 max-age 와 no-cache 가 혼용되어서 응답될 경우에 가장 제한 적인 지시자(no-cache를 의미 하는 것으로 보임)를 따라야 한다라고 좀더 명확하게 안내하고 있습니다.
2. Invalidating Stored Responses (Session 4.4) - updated
Cache invalidation of the URIs in the Location and Content-Location header fields is no longer required but is still allowed. (Section 4.4)
Cache invalidation of the URIs in the Location and Content-Location header fields is disallowed when the origin is different; previously, it was the host. (Section 4.4)
무효화 요청시 캐시컨텐츠의 응답코드 2xx 또는 3xx일 경우 가능하며, 특히 location, content-location 헤더 필드가 포함되어 있을 경우 해당 경로로 validation 요청을 트리거 할수 있었습니다.
좀더 구체적인 제안으로 무효화할 URI의 출처 Origin과 URI가 다른경우 무조건 무효화를 트리거 하면 안된다고 명시 되어 있으며, 여기서 기존 RFC-7234에서 host라는 명칭 대신 RFC-9111 에서는 Origin으로 명칭이 변경 되었습니다.
3. Age (Session 5.1) - updated
Handling invalid and multiple Age header field values has been clarified. (Section 5.1)
Age헤더의 필드 값에 대해 이전보다 좀더 구체적으로 제약 사항들이 명시 되었습니다.
- 하나의 개체만 가지는 헤더 필드로 정의되어 있지만 목록 기반 Age 필드 값이 있는 메시지를 응답받게 된다면, 캐시는 필드 값의 첫 번째 멤버를 사용하고 후속 값은 버려야 합니다.
- 위에 이어 음수가 아닌 정수 이외의 것을 포함하는 경우에 캐시는 해당 필드를 무시해야 합니다. (SHOULD)
4. Cache-Control (Session 5.2) - updated
Some cache directives defined by this specification now have stronger prohibitions against generating the quoted form of their values, since this has been found to create interoperability problems. Consumers of extension cache directives are no longer required to accept both token and quoted-string forms, but they still need to parse them properly for unknown extensions. (Section 5.2)
HTTP Caching에서 가장 중요한 헤더 필드일 것입니다. RFC-7234에서 정의된 cache-control 헤더의 일부 지시문(directives)들에 대해 좀더 명확하게 설명을 추가하였습니다.
그리고, 정의된 캐시 지시자를 재생성 하는 것을 강력하게 제한하여 End-user 간의 상호 운용성에 혼란을 일으키기는 것을 방지하도록 추가 되었습니다.
확장 캐시 지시자(5.2.3. Extension Directives) 에서는 애플리케이션에서 알수 없는 확장에 대해 적절하게 구문 분석을 통해 캐시에 영향이 없이 모두 수락 하지 않도록 구현 되도록 고려해야 할 사항들에 대해 업데이트 되었습니다.
5. Response Directives (Session 5.2.2) - updated
The public and private cache directives were clarified, so that they do not make responses reusable under any condition. (Section 5.2.2)
응답 지시자 Public과 Private 에 대해서 좀더 명확하게 업데이트 되었습니다. 특히 Private 지시자의 경우 어떤 경우에도 재사용을 금지 하도록 명시하고 있습니다.
6. must-understand (Session 5.2.2.3) - new
The must-understand cache directive was introduced; caches are no longer required to understand the semantics of new response status codes unless it is present. (Section 5.2.2.3)
새로운 Cache-Control response 지시자 입니다. 206 Partial Content 또는 304 Not Modified 상태 코드응답이나 must-understand지시자가 있는 경우 캐싱 요구 사항을 이해하는 경우에만 응답을 저장해야 함을 나타냅니다.
만약 must-understand가 지원되지 않는경우 fallback을 위해 no-store와 결합되어 응답되어야 합니다.
Cache-Control: must-understand, no-store
예시를 들면,
- 캐시가
must-understand를 지원하지 않으면 무시됩니다. 그리고no-store도 있으면 응답이 저장되지 않습니다. - 캐시가
must-understand를 지원하는 경우 상태 코드를 기반으로 캐시 요구 사항(Session 3) 을 이해하여 응답을 저장합니다.
7. Warning (Session 5.5) - obsoleted
The Warning response header was obsoleted. Much of the information supported by Warning could be gleaned by examining the response, and the remaining information — although potentially useful — was entirely advisory. In practice, Warning was not added by caches or intermediaries. (Section 5.5)
캐시는 캐시된 객체에 대한 유효성에 관련된 정보를 전달하는 용도로 Warning헤더를 전달 해줄 수 있었습니다. 이 헤더의 정보에 따라 오래된 캐시인지, 재검증 상태에 대해서 전달 받을수 있었습니다.
하지만 이 헤더가 폐기(obsoleted)된 이유는, 대부분 중계자(intermediaries = 아마 CDN Provider or Proxy)에서 응답시 사용되고 있지 않고 있습니다. 그리고 여러 다른 헤더와 Cache-Control 헤더의 지시자를 통해 충분히 정보를 얻을 수 있습니다. 대표적인 예로 Age 헤더와 Cache-Control 지시자인 stale-while-revalidate 입니다.
지난 2023년 5월 AWS CloudFront에 Cache-Control 헤더의 지시자 stale-while-revalidate와 stale-if-error를 서포트 한다고 공식 발표 하였습니다.
Amazon CloudFront now supports stale-while-revalidate and stale-if-error cache control directives
https://aws.amazon.com/ko/about-aws/whats-new/2023/05/amazon-cloudfront-stale-while-revalidate-stale-if-error-cache-control-directives/
Warning 헤더대신 캐시된 객체의 유효성에 대한 정보를 얻을 수 있습니다.
도움이 되셨으면 좋겠습니다.
Fin.
