HTTP イミュータブル応答

これはインターネット標準化トラック文書です。

本書はインターネット技術標準化委員会（IETF）の成果物です。本書はIETFコミュニティの合意を表しています。公開のために一般レビューを経て、インターネット技術運営指導グループ（IESG）によって承認されています。インターネット標準に関する詳細はRFC 7841のセクション2を参照してください。

本書の現在のステータス、正誤情報、フィードバックの提供方法などは、https://www.rfc-editor.org/info/rfc8246で入手できます。

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

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

HTTPの新鮮さ有効期間メカニズム [RFC7234] により、クライアントは一定期間、保存済みのレスポンスを安全に再利用して将来のリクエストに応答することができます。しかし、その期間中にリソースが変更される可能性は依然として存在します。

例えば、フロントページの新聞写真が1時間の新鮮さ有効期間を持つ場合、1時間以上古い写真をキャッシュから見るユーザーはいません。しかし、写真はいつでも更新される可能性があるため、最大1時間の間、異なるユーザーがキャッシュ内容に応じて異なる写真を見ることになります。これは [RFC7234] で定義されたキャッシュメカニズムに準拠しています。

キャッシュ済みレスポンスが更新されていないことを確認したいユーザーは、通常、ユーザーエージェントのリロード（またはリフレッシュ）機能を利用します。これにより条件付きリクエスト [RFC7232] が発行され、リソースが未変更の場合は304（Not Modified）レスポンス [RFC7232] が返されます。HTMLを理解し依存サブリソースを取得するユーザーエージェントは、一般的なページのすべての部分をリフレッシュするために何百もの条件付きリクエストを発行する場合があります [REQPERPAGE]。

しかし、いくつかのコンテンツプロバイダーは「バージョン付き」URLを使用することで、サブリソースのバリアントを一つしか作成しません。これらのリソースを更新する必要がある場合、新しいURLで公開され（通常はバージョン固有の識別子をパスに埋め込む）、サブリソースへの参照も新しいパス情報に更新されます。

例えば、https://www.example.com/101016/main.css が更新され https://www.example.com/102026/main.css として再公開され、それを参照するリンクも同時に変更される場合です。この設計パターンにより、今後いつ更新されるかを予測せずとも、サブリソースに非常に長い新鮮さ有効期間を設定できます。

残念ながら、ユーザーエージェントはこのバージョン付きURL設計パターンが使われているかどうかを知ることができません。その結果、ユーザー主導のリフレッシュは依然として各サブリソースごとに無駄な条件付きリクエストを発生させ、それぞれ304レスポンスを返します。

イミュータブルなHTTPレスポンス Cache-Control 拡張により、サーバーは新鮮さ有効期間内に更新されないレスポンスであることを示すことができます。

これにより、クライアントはそのレスポンスに対する条件付きリクエストを安全に省略でき、更新有無を心配する必要がなくなります。

HTTPレスポンスにイミュータブル Cache-Control 拡張が含まれている場合、オリジンサーバーはそのレスポンスの新鮮さ有効期間中にリソース表現を更新しないことを示します。

クライアントは、ユーザーによる明示的な指示（例：強制リロード）がない限り、レスポンスの新鮮さ有効期間中に条件付きリクエスト（例：リロード時）を発行すべきではありません。

イミュータブル拡張は保存済みレスポンスの新鮮さ有効期間中のみ有効です。古くなった（stale）レスポンスは、イミュータブル拡張がない場合と同様に再検証されるべきです。

イミュータブル拡張は引数を取りません。もし引数が与えられても無意味であり、無視しなければなりません。イミュータブル拡張が複数回指定されても、一度指定された場合と同じ意味になります。リクエストのCache-Control拡張としてイミュータブルが指定されても効果はありません。

• クライアントは、HTTPSなどの認証付きコンテキスト以外のリソースからのイミュータブル拡張を無視すべきです。認証済みリソースはキャッシュポイズニングのリスクが低くなります。
• ユーザーエージェントは通常、リロードと強制リロードの2種類のリフレッシュ機能を提供します。後者は中断されたロードやその他の破損を修正するために用いられます。これらのリロード（通常はno-cacheリクエスト属性で示される）は、イミュータブル拡張も無視すべきです。
• 保存済みレスポンスのサイズが正しいと強く示唆されないリソース（例えばコネクション切断によって区切られるレスポンス）に対しては、クライアントはイミュータブル拡張を無視すべきです。

イミュータブル拡張は、セクション7.1のガイドラインに従い、“Hypertext Transfer Protocol (HTTP) Cache Directive Registry” に登録されています [RFC7234]。

• Cache Directive: immutable
• Reference: RFC 8246

このアイデアの開発とテストに協力してくれたBen Maurerに感謝します。プロキシとの相互作用に関してはAmos Jeffriesに、ドキュメント化についてはMark Nottinghamに感謝します。