メインコンテンツまでスキップ

6. 履歴リスト (History Lists)

ユーザーエージェントには、セッションで以前に取得された表現を再表示するために使用できる「戻る」ボタンや履歴リストなどの履歴メカニズムがよくあります。

鮮度モデル (セクション 4.2) は、履歴メカニズムに必ずしも適用されるわけではありません。つまり、履歴メカニズムは、期限切れであっても、以前の表現を表示できます。

これは、履歴メカニズムがビューが古くなっている可能性があることをユーザーに通知すること、またはキャッシュディレクティブ (例えば、Cache-Control: no-store) を尊重することを禁止するものではありません。

7. IANA の考慮事項 (IANA Considerations)

7.1. キャッシュディレクティブレジストリ (Cache Directive Registry)​

「ハイパーテキスト転送プロトコル (HTTP) キャッシュディレクティブレジストリ」は、キャッシュディレクティブの名前空間を定義します。これは作成され、現在 http://www.iana.org/assignments/http-cache-directives で維持されています。

7.1.1. 手順 (Procedure)​

登録には以下のフィールドを含める必要があります (MUST):

  • キャッシュディレクティブ名 (Cache Directive Name)
  • 仕様テキストへのポインタ (Pointer to specification text)

この名前空間に追加される値には、IETF レビューが必要です ([RFC5226]、セクション 4.1 を参照)。

7.1.2. 新しいキャッシュ制御ディレクティブの考慮事項 (Considerations for New Cache Control Directives)​

新しい拡張ディレクティブは、以下を定義することを検討すべきです (OUGHT):

  • ディレクティブが複数回指定されることの意味、
  • ディレクティブが引数を受け入れない場合、引数が存在することの意味、
  • ディレクティブが引数を必要とする場合、それが欠落していることの意味、
  • ディレクティブがリクエスト、レスポンス、またはその両方で使用できるかどうか。

セクション 5.2.3 も参照してください。

7.1.3. 登録 (Registrations)​

レジストリには以下の登録が入力されています:

キャッシュディレクティブ (Cache Directive)参照 (Reference)
max-ageセクション 5.2.1.1、セクション 5.2.2.8
max-staleセクション 5.2.1.2
min-freshセクション 5.2.1.3
must-revalidateセクション 5.2.2.1
no-cacheセクション 5.2.1.4、セクション 5.2.2.2
no-storeセクション 5.2.1.5、セクション 5.2.2.3
no-transformセクション 5.2.1.6、セクション 5.2.2.4
only-if-cachedセクション 5.2.1.7
privateセクション 5.2.2.6
proxy-revalidateセクション 5.2.2.7
publicセクション 5.2.2.5
s-maxageセクション 5.2.2.9
stale-if-error[RFC5861]、セクション 4
stale-while-revalidate[RFC5861]、セクション 3

7.2. 警告コードレジストリ (Warn Code Registry)​

「ハイパーテキスト転送プロトコル (HTTP) 警告コード」レジストリは、警告コードの名前空間を定義します。これは作成され、現在 http://www.iana.org/assignments/http-warn-codes で維持されています。

7.2.1. 手順 (Procedure)​

登録には以下のフィールドを含める必要があります (MUST):

  • 警告コード (3 桁) (Warn Code (3 digits))
  • 簡単な説明 (Short Description)
  • 仕様テキストへのポインタ (Pointer to specification text)

この名前空間に追加される値には、IETF レビューが必要です ([RFC5226]、セクション 4.1 を参照)。

7.2.2. 登録 (Registrations)​

レジストリには以下の登録が入力されています:

警告コード (Warn Code)簡単な説明 (Short Description)参照 (Reference)
110レスポンスは古い (Response is Stale)セクション 5.5.1
111再検証失敗 (Revalidation Failed)セクション 5.5.2
112切断操作 (Disconnected Operation)セクション 5.5.3
113ヒューリスティック期限切れ (Heuristic Expiration)セクション 5.5.4
199その他の警告 (Miscellaneous Warning)セクション 5.5.5
214変換適用済み (Transformation Applied)セクション 5.5.6
299その他の永続的警告 (Miscellaneous Persistent Warning)セクション 5.5.7

7.3. ヘッダーフィールド登録 (Header Field Registration)​

HTTP ヘッダーフィールドは、http://www.iana.org/assignments/message-headers/ で維持されている「メッセージヘッダー」レジストリに登録されています。

この文書は以下の HTTP ヘッダーフィールドを定義しているため、「永続的メッセージヘッダーフィールド名」レジストリがそれに応じて更新されました ([BCP90] を参照)。

ヘッダーフィールド名 (Header Field Name)プロトコル (Protocol)ステータス (Status)参照 (Reference)
Agehttpstandardセクション 5.1
Cache-Controlhttpstandardセクション 5.2
Expireshttpstandardセクション 5.3
Pragmahttpstandardセクション 5.4
Warninghttpstandardセクション 5.5

変更管理者は: "IETF ([email protected]) - Internet Engineering Task Force"。

8. セキュリティの考慮事項 (Security Considerations)

このセクションは、HTTP キャッシングに特有の既知のセキュリティ問題について、開発者、情報提供者、およびユーザーに通知することを目的としています。より一般的なセキュリティの考慮事項は、HTTP メッセージング [RFC7230] およびセマンティクス [RFC7231] で扱われています。

キャッシュは追加の潜在的な脆弱性を露出します。キャッシュの内容は悪意のある利用の魅力的なターゲットを表すためです。キャッシュの内容は HTTP リクエストが完了した後も持続するため、キャッシュへの攻撃は、ユーザーが情報がネットワークから削除されたと信じてから長い時間が経過した後に情報を明らかにする可能性があります。したがって、キャッシュの内容は機密情報として保護される必要があります。

特に、さまざまな攻撃は共有キャッシュに保存されることで増幅される可能性があります。このような「キャッシュ汚染」攻撃は、キャッシュを使用して多くのクライアントに悪意のあるペイロードを配布し、攻撃者が実装の欠陥、昇格された権限、またはその他の技術を使用してそのようなレスポンスをキャッシュに挿入できる場合に特に効果的です。キャッシュ汚染の一般的な攻撃ベクトルは、プロキシとユーザーエージェントでのメッセージ解析の違いを悪用することです。関連する要件については、[RFC7230] のセクション 3.3.3 を参照してください。

同様に、実装の欠陥 (およびキャッシュ操作の誤解) は、プライベートであると考えられる機密情報 (例えば、認証資格情報) のキャッシュにつながり、それを許可されていない当事者に露出させる可能性があります。

さらに、キャッシュの使用自体がプライバシーの懸念を引き起こす可能性があります。例えば、2 人のユーザーがキャッシュを共有し、最初のユーザーがサイトを閲覧した場合、2 番目のユーザーは、キャッシュのおかげでそのサイトからのリソースがより速く読み込まれるため、もう一方のユーザーがそのサイトに行ったことを検出できる可能性があります。

Set-Cookie レスポンスヘッダーフィールド [RFC6265] はキャッシングを抑制しないことに注意してください。Set-Cookie ヘッダーフィールドを持つキャッシュ可能なレスポンスは、キャッシュへの後続のリクエストを満たすために使用できます (そしてしばしば使用されます)。これらのレスポンスのキャッシングを制御したいサーバーは、適切な Cache-Control レスポンスヘッダーフィールドを発行することが推奨されます。

9. 謝辞 (Acknowledgments)

[RFC7230] のセクション 10 を参照してください。

10. 参考文献 (References)

10.1. 規範的参考文献 (Normative References)​

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

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. 参考情報 (Informative References)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [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.

  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

  • [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

  • [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

付録 A. RFC 2616 からの変更点 (Changes from RFC 2616)

仕様は明確性のために大幅に書き直されました。

認証されたレスポンスをキャッシュできる条件が明確化されました。(セクション 3.2)

新しいステータスコードは、キャッシュがそれらでヒューリスティック鮮度を使用することを許可するように定義できるようになりました。キャッシュは、クエリコンポーネントを持つ URI のヒューリスティック鮮度を計算することが許可されるようになりました。(セクション 4.2.2)

年齢を計算するアルゴリズムは、より保守的でなくなりました。キャッシュは、タイムゾーンを持つ日付を無効として扱うことが要求されるようになりました。正確に推測することができないためです。(セクション 4.2.3)

Content-Location レスポンスヘッダーフィールドは、検証時に使用する適切なレスポンスを決定するために使用されなくなりました。(セクション 4.3)

使用するキャッシュされたネゴシエートされたレスポンスを選択するアルゴリズムは、いくつかの方法で明確化されました。特に、選択ヘッダーフィールドを処理する際に、ヘッダー固有の正規化を明示的に許可するようになりました。(セクション 4.1)

無効化を実行する際のサービス拒否攻撃の回避に関する要件が明確化されました。(セクション 4.4)

キャッシュの無効化は、成功したレスポンスが受信された場合にのみ発生します。(セクション 4.4)

キャッシュディレクティブは、大文字と小文字を区別しないと明示的に定義されました。1 つだけが期待される場合のキャッシュディレクティブの複数のインスタンスの処理が定義されました。(セクション 5.2)

"no-store" リクエストディレクティブはレスポンスに適用されません。つまり、キャッシュは no-store を持つリクエストを満たすことができ、それを無効化しません。(セクション 5.2.1.5 節)

private および no-cache キャッシュディレクティブの修飾形式は、広く実装されていないことが指摘されています。たとえば、"private=foo" は多くのキャッシュによって単に "private" として解釈されます。さらに、no-cache の修飾形式の意味が明確化されました。(セクション 5.2.2)

"no-cache" レスポンスディレクティブの意味が明確化されました。(セクション 5.2.2.2)

Expires ヘッダーフィールド値の 1 年制限は削除されました。代わりに、妥当な値を使用する理由が示されています。(セクション 5.3)

Pragma ヘッダーフィールドは、後方互換性のためにのみ定義されるようになりました。将来の pragma は非推奨です。(セクション 5.4)

Warning ヘッダーフィールドの生成と処理に関するいくつかの要件が緩和されました。広く実装されていないためです。さらに、Warning ヘッダーフィールドは RFC 2047 エンコーディングを使用しなくなり、複数の言語も許可しなくなりました。これらの側面が実装されていないためです。(セクション 5.5)

この仕様は、キャッシュディレクティブおよび警告コードレジストリを導入し、新しいキャッシュディレクティブの考慮事項を定義します。(セクション 7.1 およびセクション 7.2)

付録 B. インポートされた ABNF (Imported ABNF)

以下のコアルールは、[RFC5234] の付録 B.1 で定義されているように、参照により含まれています: ALPHA (文字)、CR (キャリッジリターン)、CRLF (CR LF)、CTL (制御)、DIGIT (10 進数 0-9)、DQUOTE (二重引用符)、HEXDIG (16 進数 0-9/A-F/a-f)、LF (ラインフィード)、OCTET (任意の 8 ビットデータシーケンス)、SP (スペース)、および VCHAR (任意の可視 US-ASCII 文字)。

以下のルールは [RFC7230] で定義されています:

OWS           = <OWS, [RFC7230]、セクション 3.2.3 を参照>
field-name    = <field-name, [RFC7230]、セクション 3.2 を参照>
quoted-string = <quoted-string, [RFC7230]、セクション 3.2.6 を参照>
token         = <token, [RFC7230]、セクション 3.2.6 を参照>

port          = <port, [RFC7230]、セクション 2.7 を参照>
pseudonym     = <pseudonym, [RFC7230]、セクション 5.7.1 を参照>
uri-host      = <uri-host, [RFC7230]、セクション 2.7 を参照>

以下のルールは他の部分で定義されています:

HTTP-date     = <HTTP-date, [RFC7231]、セクション 7.1.1.1 を参照>

付録 C. 収集された ABNF (Collected ABNF)

以下に収集された ABNF では、リストルールは [RFC7230] のセクション 1.2 に従って展開されています。

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, [RFC7231]、セクション 7.1.1.1 を参照>

OWS = <OWS, [RFC7230]、セクション 3.2.3 を参照>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, [RFC7230]、セクション 3.2 を参照>

port = <port, [RFC7230]、セクション 2.7 を参照>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, [RFC7230]、セクション 5.7.1 を参照>

quoted-string = <quoted-string, [RFC7230]、セクション 3.2.6 を参照>

token = <token, [RFC7230]、セクション 3.2.6 を参照>

uri-host = <uri-host, [RFC7230]、セクション 2.7 を参照>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

著者のアドレス (Authors' Addresses)​

Roy T. Fielding (編集者)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

EMail: [email protected]
URI: http://roy.gbiv.com/

Mark Nottingham (編集者)
Akamai

EMail: [email protected]
URI: http://www.mnot.net/

Julian F. Reschke (編集者)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/

に最終更新