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

1. 序論 (Introduction)

HTTPは通常、分散情報システムで使用され、レスポンスキャッシュの使用によりパフォーマンスを向上させることができる。本文書は、キャッシュとレスポンスメッセージの再利用に関連するHTTP/1.1の側面を定義する。

HTTPキャッシュ (HTTP Cache) は、レスポンスメッセージのローカルストアであり、その中のメッセージの保存、取得、削除を制御するサブシステムである。キャッシュは、将来の同等のリクエストに対するレスポンス時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを保存する。クライアントまたはサーバーはキャッシュを使用してもよい (MAY) が、トンネルとして機能するサーバーはキャッシュを使用できない。

共有キャッシュ (Shared Cache) は、複数のユーザーによって再利用されるレスポンスを保存するキャッシュである; 共有キャッシュは通常（常にではないが）中継者の一部として展開される。対照的に、プライベートキャッシュ (Private Cache) は単一のユーザー専用である; 多くの場合、ユーザーエージェントのコンポーネントとして展開される。

HTTP/1.1におけるキャッシュの目標は、以前のレスポンスメッセージを再利用して現在のリクエストを満たすことにより、パフォーマンスを大幅に向上させることである。第4.2節で定義されているように、レスポンスが「検証」(Validation)（キャッシュされたレスポンスがこのリクエストに対して依然として有効であるかどうかをオリジンサーバーで確認すること）なしで再利用できる場合、保存されたレスポンスは「新鮮」(Fresh) であると見なされる。したがって、新鮮なレスポンスは、再利用されるたびにレイテンシとネットワークオーバーヘッドの両方を削減できる。キャッシュされたレスポンスが新鮮でない場合でも、検証によって更新できる場合（第4.3節）、またはオリジンが利用できない場合（第4.2.4節）は、再利用可能である可能性がある。

1.1. 適合性とエラー処理 (Conformance and Error Handling)​

本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119] に記載されているように解釈されるものとする。

適合性基準およびエラー処理に関する考慮事項は、[RFC7230] のセクション2.5で定義されている。

1.2. 構文表記 (Syntax Notation)​

本仕様は、[RFC5234] の拡張バッカス・ナウア記法 (ABNF) を使用し、[RFC7230] のセクション7で定義されているリスト拡張を使用する。これにより、'#' 演算子を使用してカンマ区切りリストをコンパクトに定義できる（'*' 演算子が繰り返しを示すのと同様）。付録Bは他の文書からインポートされたルールを説明する。付録Cは、すべてのリスト演算子が標準ABNF表記に展開された収集文法を示す。

1.2.1. デルタ秒 (Delta Seconds)​

delta-secondsルールは、秒単位の時間を表す非負整数を指定する。

delta-seconds = 1*DIGIT

delta-seconds値を解析してバイナリ形式に変換する受信者は、少なくとも31ビットの非負整数範囲の算術型を使用すべきである (ought to)。キャッシュが表現できる最大整数よりも大きいdelta-seconds値を受信した場合、またはその後の計算でオーバーフローが発生した場合、キャッシュはその値を2147483648 (2^31) または便利に表現できる最大の正整数と見なさなければならない (MUST)。

注: 値2147483648は歴史的な理由で存在し、バイナリ形式で保存されるのではなく、無限大（68年以上）を表す; 計算に使用される算術型がその数値を直接表現できない場合でも、実装はオーバーフローが発生したときにそれを固定文字列として生成できる。ここで重要なのは、オーバーフローが検出され、その後負の値として扱われないことである。