インターネット技術標準化委員会 (IETF)

M. Nottingham

Request for Comments: 5861

Yahoo! Inc.

カテゴリ: 情報提供

2010年5月

ISSN: 2070-1721

古いコンテンツのためのHTTP Cache-Control拡張

概要

本書は、キャッシュによる古い応答の利用を制御できる、2つの独立した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. はじめに
2. 記法上の規約
3. stale-while-revalidate Cache-Control 拡張
- 3.1. 例
4. stale-if-error Cache-Control 拡張
- 4.1. 例
5. セキュリティに関する考慮事項
6. IANAに関する考慮事項
7. 引用規格
付録A. 謝辞
著者の連絡先

1. はじめに

HTTP [RFC2616]は、キャッシュが「要求に適切な、保持している最新の応答で応答する」ことを要求していますが、「慎重に管理された状況下」では古い応答を返すことも許可されています。本書は、そのような制御を可能にする2つの独立したCache-Control拡張（stale-if-errorおよびstale-while-revalidate）を定義します。

stale-if-error HTTP Cache-Control拡張は、エラー（例えば500 Internal Server Error、ネットワーク区間、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]の拡張バッカス・ナウア記法（ABNF）を使用し、同仕様からdelta-secondsルールを含みます。

3. stale-while-revalidate Cache-Control 拡張

HTTP応答にstale-while-revalidate Cache-Control拡張が含まれている場合、キャッシュは応答が古くなった後でも、指定された秒数まで応答を提供することができます。

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

この拡張によってキャッシュされた応答が古いまま提供される場合、キャッシュは検証を試みつつ、引き続き古い応答を提供するべきです（つまりブロックせずに）。

なお、「古い」とは、HTTPの要件に従い、応答に非ゼロのAgeヘッダおよびWarningヘッダが含まれることを意味します。

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拡張として使用される場合は、キャッシュされた応答に対するすべてのリクエストに適用されます。

この値は古さの上限を示します。キャッシュされた応答が指定された値より古い場合、他に情報がなければその応答をリクエストに使うべきではありません。

ここでいうエラーとは、500、502、503、504のHTTPレスポンスステータスコードが返される事態を指します。

このディレクティブは新鮮さに影響を与えません。使用される古いキャッシュ応答は、送信時に依然として明示的に古い状態（つまり非ゼロの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拡張は、オリジンサーバーが特定の状況下でキャッシュから古いコンテンツを提供する仕組みを指定できるようにし、キャッシュ応答がバックグラウンドで検証されることを期待しています。増幅攻撃の可能性（プリフェッチや自動リフレッシュ機構の一部に見られるような）を避けるため、受信リクエストに基づいて検証が実行されることが推奨されます。キャッシュ実装者は、ユーザーやクライアントによる直接的なリクエスト以外でどのような場合にリクエストを生成するかを決定する際、この点に留意すべきです。

stale-if-errorは、オリジンサーバーやクライアントに、特定の状況下でキャッシュから古いコンテンツを提供する仕組みを与えますが、RFC2616で既に古いコンテンツの提供が許可されているため、それ以上のセキュリティ上の考慮事項はありません。

6. IANAに関する考慮事項

本書にIANAへのアクションはありません。

7. 引用規格

[RFC2119]: Bradner, S., “RFCにおける要件レベルを示すキーワードの使用”, 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.
メール: mnot@yahoo-inc.com
URI: http://www.mnot.net/