인터넷 엔지니어링 태스크 포스 (IETF)

M. Nottingham

의견 요청: 5861

Yahoo! Inc.

분류: 정보용

2010년 5월

ISSN: 2070-1721

오래된 콘텐츠에 대한 HTTP Cache-Control 확장

요약

이 문서는 캐시가 오래된 응답을 사용하는 방법을 제어할 수 있도록 하는 두 개의 독립적인 HTTP Cache-Control 확장을 정의합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 명세가 아니며, 정보 제공을 위해 발행되었습니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 발행이 승인되었습니다. IESG에 의해 승인된 모든 문서가 인터넷 표준의 후보가 되는 것은 아닙니다. 자세한 내용은 RFC 5741의 2절을 참고하십시오.

이 문서의 최신 상태, 정오표, 피드백 방법에 대한 정보는 http://www.rfc-editor.org/info/rfc5861에서 확인할 수 있습니다.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.

1. 소개

HTTP [RFC2616]은 캐시가 "요청에 가장 적합한 최신 응답으로 응답해야 한다"고 요구하지만, "신중하게 통제된 상황"에서는 오래된 응답을 반환할 수 있다고 명시합니다. 이 문서는 이러한 제어를 가능하게 하는 두 가지 독립적인 Cache-Control 확장인 stale-if-error와 stale-while-revalidate를 정의합니다.

stale-if-error HTTP Cache-Control 확장은 오류(예: 500 내부 서버 오류, 네트워크 단절, DNS 실패 등)가 발생했을 때 "하드" 오류를 반환하는 대신 캐시가 오래된 응답을 반환할 수 있도록 허용합니다. 이는 가용성을 향상시킵니다.

stale-while-revalidate HTTP Cache-Control 확장은 캐시가 백그라운드에서 재검증을 진행하는 동안 즉시 오래된 응답을 반환할 수 있게 하여, 클라이언트로부터 네트워크 및 서버의 지연을 숨길 수 있도록 해줍니다.

2. 표기 규칙

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"과 같은 핵심 용어는 RFC 2119 [RFC2119]에 따라 해석되어야 합니다.

이 명세는 RFC2616 [RFC2616]의 확장된 Backus-Naur Form을 사용하고, 해당 명세의 delta-seconds 규칙을 포함합니다.

3. stale-while-revalidate Cache-Control 확장

HTTP 응답에 stale-while-revalidate Cache-Control 확장이 포함되어 있으면, 캐시는 해당 응답이 오래되어도 지정된 초 수만큼 계속 제공할 수 있음을 나타냅니다.

  stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds

이 확장으로 인해 캐시된 응답이 오래된 상태로 제공되는 경우, 캐시는 오래된 응답을 계속 제공하면서 동시에 재검증을 시도해야 합니다(즉, 차단하지 않고).

"오래됨(stale)"은 해당 응답이 0이 아닌 Age 헤더와 경고(warning) 헤더를 갖는다는 것을 의미함에 유의하십시오(HTTP 요구사항에 따라).

delta-seconds가 지나도록 캐시된 엔터티가 재검증되지 않으면, 다른 정보가 없는 한 오래된 상태로 계속 제공되어선 안 됩니다.

3.1. 예시

다음과 같은 응답의 경우:

  Cache-Control: max-age=600, stale-while-revalidate=30

이 응답은 600초 동안은 신선하며, 비동기 검증이 시도되는 동안 추가로 30초 동안 오래된 상태로 계속 제공될 수 있음을 의미합니다. 검증이 결론에 도달하지 못하거나, 이를 트리거하는 트래픽이 없다면, 30초 이후에는 stale-while-revalidate 기능이 동작을 멈추고 캐시된 응답은 "진짜" 오래된 상태가 됩니다(즉, 다음 요청은 차단되어 정상적으로 처리됩니다).

일반적으로 서버는 max-age와 stale-while-revalidate의 합이 허용 가능한 최대 신선 수명에 맞도록 설정하길 원할 것입니다. 예를 들어 두 값을 모두 600으로 설정하면, 서버는 최대 20분 동안 캐시에서 응답이 제공되는 것을 허용해야 합니다.

비동기 검증은 응답이 오래된 후, 그리고 stale-while-revalidate 윈도우가 끝나기 전에 요청이 발생하는 경우에만 일어나므로, 해당 윈도우의 크기와 그 안에 요청이 들어올 확률이 지연 없는 응답 제공 가능성을 결정합니다. 윈도우가 너무 작거나 트래픽이 드물면 일부 요청은 윈도우 밖에 위치하게 되어, 서버가 캐시된 응답을 검증할 때까지 차단될 수 있습니다.

4. stale-if-error Cache-Control 확장

stale-if-error Cache-Control 확장은 오류가 발생했을 때, 다른 신선도 정보와 상관없이 캐시된 오래된 응답을 사용하여 요청을 처리할 수 있음을 나타냅니다.

  stale-if-error = "stale-if-error" "=" delta-seconds

요청 Cache-Control 확장으로 사용될 때는 해당 요청에만 적용되며, 응답 Cache-Control 확장으로 사용될 때는 캐시된 응답에 적용되는 모든 요청에 적용됩니다.

이 값은 허용되는 최대 오래됨(staleness)을 나타냅니다. 캐시된 응답이 지정된 시간보다 더 오래된 경우, 다른 정보가 없는 한 해당 응답으로 요청을 처리해서는 안 됩니다.

여기서 "오류"란 500, 502, 503, 504 HTTP 응답 상태 코드가 반환되는 모든 상황을 의미합니다.

이 지시어는 신선도에 영향을 주지 않으므로, 사용되는 오래된 캐시 응답은 전송 시 반드시 0이 아닌 Age 헤더와 warning 헤더를 포함해야 합니다(HTTP 요구사항에 따라).

4.1. 예시

다음과 같은 응답의 경우:

  HTTP/1.1 200 OK
  Cache-Control: max-age=600, stale-if-error=1200
  Content-Type: text/plain
  
  success

이 응답은 600초 동안 신선하며, 이후 오류가 발생하면 오래된 상태로 추가 1200초 동안 사용할 수 있음을 의미합니다.

따라서 캐시가 900초 후에 검증을 시도하다가 다음과 같은 상황을 만나면:

  HTTP/1.1 500 Internal Server Error
  Content-Type: text/plain
  
  failure

성공적인 응답을 대신 반환할 수 있습니다:

  HTTP/1.1 200 OK
  Cache-Control: max-age=600, stale-if-error=1200
  Age: 900
  Content-Type: text/plain
  
  succcess

Age가 1800초를 초과하면(즉, 1200초 동안 오래된 상태가 유지되면), 캐시는 오류 메시지를 반드시 전송해야 합니다.

  HTTP/1.1 500 Internal Server Error
  Content-Type: text/plain
  
  failure

5. 보안 고려사항

stale-while-revalidate 확장은 원본 서버가 특정 상황에서 캐시에서 오래된 콘텐츠를 제공하도록 지시하는 메커니즘을 제공합니다. 이때 캐시된 응답이 백그라운드에서 재검증될 것으로 기대합니다. 이러한 검증은 수신된 요청에 기반하여 수행하는 것이 권장되며, 이는 일부 사전 가져오기(pre-fetching) 및 자동 새로고침 메커니즘에서 발생할 수 있는 증폭 공격 가능성을 방지하기 위함입니다. 캐시 구현자는 사용자 또는 클라이언트가 직접 시작하지 않은 요청을 생성할 조건을 결정할 때 이를 염두에 두어야 합니다.

stale-if-error는 원본 서버와 클라이언트가 특정 상황에서 캐시에서 오래된 콘텐츠를 제공하도록 지시할 수 있는 메커니즘을 제공하며, RFC2616에서 허용하는 오래된 콘텐츠 제공과 비교하여 추가적인 보안 고려사항은 없습니다.

6. IANA 고려사항

이 문서는 IANA를 위한 별도의 조치를 포함하지 않습니다.

7. 규범적 참고문헌

[RFC2119]: Bradner, S., “RFC에서 요구 수준을 나타내기 위한 핵심 용어(Key words for use in RFCs to Indicate Requirement Levels)”, BCP 14, RFC 2119, 1997년 3월.
[RFC2616]: Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., 그리고 T. Berners-Lee, “하이퍼텍스트 전송 프로토콜 -- HTTP/1.1”, RFC 2616, 1999년 6월.

부록 A. 감사의 글

Ben Drees, John Nienart, Henrik Nordstrom, Evan Torrie, Chris Westin에게 제안에 감사드립니다. 모든 오류와 누락에 대한 책임은 저자에게 있습니다.

저자 주소

Mark Nottingham
Yahoo! Inc.
EMail: mnot@yahoo-inc.com
URI: http://www.mnot.net/