RFC 5861 - HTTP Cache-Control Extensions for Stale Content 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5861
タイトル : RFC 5861 - 古いコンテンツ用のHTTPキャッシュコントロール拡張
翻訳編集 : 自動生成

[要約] RFC 5861は、古いコンテンツのキャッシュ制御を拡張するためのHTTP Cache-Controlの仕様です。目的は、キャッシュされたコンテンツが古くなった場合に、クライアントがそれを使用するかどうかを制御するための機能を提供することです。

Independent Submission                                     M. Nottingham
Request for Comments: 5861                                   Yahoo! Inc.
Category: Informational                                         May 2010
ISSN: 2070-1721

HTTP Cache-Control Extensions for Stale Content

古いコンテンツ用のHTTPキャッシュコントロール拡張

Abstract

概要

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.

このドキュメントでは、キャッシュによる古い応答の使用を制御できる2つの独立したHTTPキャッシュ制御拡張機能を定義します。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5861.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 2
   3.  The stale-while-revalidate Cache-Control Extension  . . . . . . 2
     3.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  The stale-if-error Cache-Control Extension  . . . . . . . . . . 3
     4.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 6

1. Introduction

1. はじめに

HTTP [RFC2616] requires that caches "respond to a request with the most up-to-date response held... that is appropriate to the request," although "in carefully considered circumstances" a stale response is allowed to be returned. This document defines two independent Cache-Control extensions that allow for such control, stale-if-error and stale-while-revalidate.

HTTP [RFC2616]では、キャッシュが「慎重に考慮された状況では」古い応答が返されることを許可されていますが、キャッシュが「最も最新の応答を保持している最新の応答でリクエストに応答する」ことを要求しています。このドキュメントでは、そのような制御、古い誤った、および老化のある場合に劣化する2つの独立したキャッシュコントロール拡張機能を定義します。

The stale-if-error HTTP Cache-Control extension allows a cache to return a stale response when an error -- e.g., a 500 Internal Server Error, a network segment, or DNS failure -- is encountered, rather than returning a "hard" error. This improves availability.

Stale-if-error HTTPキャッシュ制御拡張機能により、エラー（たとえば500の内部サーバーエラー、ネットワークセグメント、またはDNS障害など）が「ハード」を返すのではなく、キャッシュが露出したときに古い応答を返すことができます。" エラー。これにより、可用性が向上します。

The stale-while-revalidate HTTP Cache-Control extension allows a cache to immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients.

古くなっている場合は、HTTPキャッシュコントロール拡張機能を再検証すると、キャッシュはすぐに古い応答を返すことができます。バックグラウンドで再調整し、それによりクライアントからレイテンシ（ネットワーク内とサーバーの両方）を隠します。

2. Notational Conventions

2. 表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。

This specification uses the augmented Backus-Naur Form of RFC 2616 [RFC2616], and it includes the delta-seconds rule from that specification.

この仕様では、RFC 2616 [RFC2616]の拡張されたバックスノール形式を使用し、その仕様からのデルタ秒ルールが含まれています。

3. The stale-while-revalidate Cache-Control Extension

3. 古い場合、キャッシュ制御の拡張を再評価する場合

When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.

HTTP応答に存在する場合、古くから再平行に再生的に拡張されると、キャッシュが陳腐化した後に表示される反応に役立つことが示されていることが示されています。

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

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

If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).

この拡張機能の存在によりキャッシュされた応答が古くなっている場合、キャッシュは、まだ古い応答を提供しながら（つまり、ブロックせずに）、それを再調整しようとする必要があります。

Note that "stale" implies that the response will have a non-zero Age header and a warning header, as per HTTP's requirements.

「古い」は、HTTPの要件に従って、応答にゼロ以外の年齢ヘッダーと警告ヘッダーがあることを意味することに注意してください。

If delta-seconds passes without the cached entity being revalidated, it SHOULD NOT continue to be served stale, absent other information.

キャッシュされたエンティティが再確認されずにデルタ秒が通過する場合、他の情報がなくても、古くされ続けないでください。

3.1. Example

3.1. 例

A response containing:

含む応答：

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

indicates that it is fresh for 600 seconds, and it may continue to be served stale for up to an additional 30 seconds while an asynchronous validation is attempted. If validation is inconclusive, or if there is not traffic that triggers it, after 30 seconds the stale-while-revalidate function will cease to operate, and the cached response will be "truly" stale (i.e., the next request will block and be handled normally).

600秒間新鮮であることを示し、非同期検証が試みられている間、さらに30秒まで古くなって提供され続ける可能性があります。検証が決定的ではない場合、またはそれをトリガーするトラフィックがない場合、30秒後には、古くからの再平行機能の動作が停止し、キャッシュされた応答が「本当に」古くなります（つまり、次のリクエストはブロックされ、正常に処理されます）。

Generally, servers will want to set the combination of max-age and stale-while-revalidate to the longest total potential freshness lifetime that they can tolerate. For example, with both set to 600, the server must be able to tolerate the response being served from cache for up to 20 minutes.

一般的に、サーバーは、最大年齢と古くなった場合の古くなった場合の組み合わせを、耐えられる最も長い潜在的な新鮮な寿命に設定したいと考えています。たとえば、両方が600に設定されている場合、サーバーは最大20分間キャッシュから提供される応答を許容できる必要があります。

Since asynchronous validation will only happen if a request occurs after the response has become stale, but before the end of the stale-while-revalidate window, the size of that window and the likelihood of a request during it determines how likely it is that all requests will be served without delay. If the window is too small, or traffic is too sparse, some requests will fall outside of it, and block until the server can validate the cached response.

非同期検証は、応答が古くなった後にリクエストが発生した場合にのみ発生するため、陳腐化した場合の陳腐化の場合、そのウィンドウのサイズとその中のリクエストの可能性は、それがどれだけの可能性であるかを決定するため、リクエストは遅滞なく提供されます。ウィンドウが小さすぎる場合、またはトラフィックがまばらである場合、一部のリクエストはその外側に収まり、サーバーがキャッシュされた応答を検証できるまでブロックします。

4. The stale-if-error Cache-Control Extension

4. 古いキャッシュコントロール拡張機能

The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.

古いキャッシュコントロール拡張機能は、エラーが発生したときに、他の新鮮さの情報に関係なく、要求を満たすためにキャッシュされた古い応答を使用できることを示しています。

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

When used as a request Cache-Control extension, its scope of application is the request it appears in; when used as a response Cache-Control extension, its scope is any request applicable to the cached response in which it occurs.

要求キャッシュコントロール拡張機能として使用する場合、そのアプリケーションの範囲は、表示されるリクエストです。応答キャッシュコントロール拡張として使用される場合、そのスコープは、発生するキャッシュされた応答に適用される要求です。

Its value indicates the upper limit to staleness; when the cached response is more stale than the indicated amount, the cached response SHOULD NOT be used to satisfy the request, absent other information.

その値は、老化の上限を示しています。キャッシュされた応答が示された量よりも古い場合、キャッシュされた応答を使用して要求を満たすために使用しないでください。

In this context, an error is any situation that would result in a 500, 502, 503, or 504 HTTP response status code being returned.

これに関連して、エラーとは、500、502、503、または504 HTTP応答ステータスコードが返される状況です。

Note that this directive does not affect freshness; stale cached responses that are used SHOULD still be visibly stale when sent (i.e., have a non-zero Age header and a warning header, as per HTTP's requirements).

この指令は新鮮さに影響しないことに注意してください。使用される古いキャッシュされた応答は、送信時にまだ目に見えて古くする必要があります（つまり、HTTPの要件に従って、ゼロ以外の年齢ヘッダーと警告ヘッダーがあります）。

4.1. Example

4.1. 例

A response containing:

含む応答：

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

success

成功

indicates that it is fresh for 600 seconds, and that it may be used if an error is encountered after becoming stale for an additional 1200 seconds.

600秒間新鮮であり、さらに1200秒間古くなった後にエラーが発生した場合に使用できることを示します。

Thus, if the cache attempts to validate 900 seconds afterwards and encounters:

したがって、キャッシュが900秒後に検証しようとして出会いを試みた場合：

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

failure

失敗

the successful response can be returned instead:

代わりに、成功した応答を返すことができます。

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

success

成功

After the age is greater than 1800 seconds (i.e., it has been stale for 1200 seconds), the cache must write the error message through.

年齢が1800秒を超えた後（つまり、1200秒間古くなっています）、キャッシュはエラーメッセージを書き込む必要があります。

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

failure

失敗

5. Security Considerations

5. セキュリティに関する考慮事項

The stale-while-revalidate extension provides origin servers with a mechanism for dictating that stale content should be served from caches under certain circumstances, with the expectation that the cached response will be revalidated in the background. It is suggested that such validation be predicated upon an incoming request, to avoid the possibility of an amplification attack (as can be seen in some other pre-fetching and automatic refresh mechanisms). Cache implementers should keep this in mind when deciding the circumstances under which they will generate a request that is not directly initiated by a user or client.

古い場合に再バリデート拡張は、特定の状況下でキャッシュから古いコンテンツをキャッシュから提供する必要があることを決定するためのメカニズムをオリジンサーバーに提供し、キャッシュされた応答がバックグラウンドで再確認されることを期待しています。そのような検証は、増幅攻撃の可能性を回避するために、着信要求に基づいていることが示唆されています（他のいくつかのフェッチング前および自動更新メカニズムで見られるように）。キャッシュ実装者は、ユーザーまたはクライアントによって直接開始されないリクエストを生成する状況を決定する際に、これを念頭に置いておく必要があります。

The stale-if-error provides origin servers and clients a mechanism for dictating that stale content should be served from caches under certain circumstances, and does not pose additional security considerations over those of RFC 2616, which also allows stale content to be served.

Stale-If-Errorは、Origin Serverとクライアントに、特定の状況下で古いコンテンツをキャッシュから提供する必要があることを決定するためのメカニズムを提供し、RFC 2616のセキュリティに関する追加の考慮事項を提起しません。これにより、古いコンテンツが提供されます。

6. Normative References

6. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。

Appendix A. Acknowledgements

付録A. 謝辞

Thanks to Ben Drees, John Nienart, Henrik Nordstrom, Evan Torrie, and Chris Westin for their suggestions. The author takes all responsibility for errors and omissions.

ベン・ドリース、ジョン・ニーナート、ヘンリック・ノードストローム、エヴァン・トーリー、クリス・ウェスティンの提案に感謝します。著者は、エラーと省略に対してすべての責任を負います。

Author's Address

著者の連絡先

Mark Nottingham Yahoo! Inc.

マーク・ノッティンガム・ヤフー！Inc.

   EMail: mnot@yahoo-inc.com
   URI:   http://www.mnot.net/