13. Caching in HTTP (HTTPキャッシング)

13 Caching in HTTP

HTTP は通常、分散情報システムに使われる。そこではレスポンスキャッシュを使うことで性能を改善できる。HTTP/1.1 プロトコルには、キャッシュをできる限りうまく機能させることを意図した多くの要素が含まれている。これらの要素はプロトコルの他の側面から切り離せず、また互いに作用し合うため、HTTP の基本的なキャッシュ設計は、method、header、response code などの詳細な説明とは別に記述するのが有用である。

キャッシュが性能を大幅に改善しないのであれば、それは無用である。HTTP/1.1 におけるキャッシュの目標は、多くの場合に request を送る必要性を排除し、さらに他の多くの場合に完全な response を送る必要性を排除することである。前者は多くの操作に必要なネットワーク往復回数を削減する; この目的のために「expiration」メカニズムを使う (13.2 節参照)。後者はネットワーク帯域幅の要件を削減する; この目的のために「validation」メカニズムを使う (13.3 節参照)。

性能、可用性、および切断状態での動作の要件は、我々が意味的透過性 (semantic transparency) という目標を緩和できることを要求する。HTTP/1.1 プロトコルは、origin server、cache、および client が、必要なときに透過性を明示的に下げることを許容する。しかし、非透過的な動作は非熟練のユーザを混乱させるおそれがあり、(商品の注文処理のような) 特定の server application と両立しないおそれがあるため、プロトコルは次の場合にのみ透過性の緩和を要求する:

  - client または origin server によって緩和される場合は、明示的なプロトコルレベル request によってのみ

  - cache または client によって緩和される場合は、エンドユーザへの明示的な warning を伴う場合にのみ

したがって、HTTP/1.1 プロトコルは次の重要な要素を提供する:

  1. すべての当事者がそれを要求する場合に完全な意味的透過性を提供するプロトコル機能。

  2. origin server または user agent が、非透過的な動作を明示的に要求し制御できるようにするプロトコル機能。

  3. cache が、要求された意味的透過性の近似を保たない response に warning を付加できるようにするプロトコル機能。

基本原則は、client が意味的透過性の潜在的な緩和を検出できなければならないということである。

  Note: server、cache、または client の実装者は、本仕様で明示的に論じられていない設計上の判断に直面するかもしれない。その判断が意味的透過性に影響しうる場合、透過性を破ることによる重要な利点があることを注意深く完全な分析が示さない限り、実装者は透過性を維持する側に倒すべきである。

13.1.1 Cache Correctness (キャッシュの正確性)

正しい cache は、request に適切であり、かつ次のいずれかの条件を満たす、cache が保持する最新の response で request に応答しなければならない (MUST) (13.2.5 節、13.2.6 節、および 13.12 節参照):

  1. origin server で response を再検証することにより、origin server が返したであろう response との等価性が確認されている (13.3 節)。

  2. それが「十分に新鮮」である (13.2 節参照)。デフォルトの場合、これは client、origin server、および cache のうち最も制限の少ない新鮮度要件を満たすことを意味する (14.9 節参照); origin server がそのように指定する場合は、origin server だけの新鮮度要件である。

     保存された response が、client と origin server の両方の最も制限の強い新鮮度要件によって「十分に新鮮」でない場合、注意深く検討された状況において、cache は適切な Warning ヘッダを付けてその response を返してもよい (MAY) — ただしそのような response が (例えば「no-store」cache-directive、または「no-cache」cache-request-directive によって) 禁止されている場合を除く (13.1.5 節および 14.46 節参照)。

  3. それが適切な 304 (Not Modified)、305 (Proxy Redirect)、またはエラー (4xx または 5xx) response message である。

cache が origin server と通信できない場合、正しい cache は、その response を cache から正しく提供できるなら上記のように応答すべきである (SHOULD); そうでなければ、通信障害があったことを示すエラーまたは warning を返さなければならない (MUST)。

cache が、(完全な response であれ 304 (Not Modified) response であれ) 通常なら要求元 client に転送するであろう response を受け取り、受信した response がもはや新鮮でない場合、cache は新しい Warning を付加することなく (ただし既存の Warning ヘッダを削除することもなく) それを要求元 client に転送すべきである (SHOULD)。cache は、response が転送中に古くなったというだけの理由でその response を再検証しようとすべきではない (SHOULD NOT); これは無限ループを招くおそれがある。Warning のない古い response を受け取った user agent は、ユーザに warning 表示を行ってもよい (MAY)。

13.1.2 Warnings (警告)

cache が first-hand でも「十分に新鮮」でもない (13.1.1 節の条件 2 の意味での) response を返すときは常に、Warning general-header を使ってその旨の warning を付加しなければならない (MUST)。Warning ヘッダおよび現在定義されている warning は 14.46 節で述べる。warning により、client は適切な行動をとることができる。

warning は、キャッシュ関連およびその他の両方の目的で使ってもよい (MAY)。warning を使い、error status code を使わないことで、これらの response を真の failure と区別する。

warning には 3 桁の warn-code が割り当てられる。最初の桁は、成功した再検証の後で Warning を格納された cache entry から削除しなければならない (MUST) か、削除してはならない (MUST NOT) かを示す:

1xx 成功した再検証の後で削除しなければならない (MUST)、response の新鮮度または再検証状態を記述する warning。1xx warn-code は、cache が cached entry を検証するときにのみ生成してもよい (MAY)。client が生成してはならない (MUST NOT)。

2xx 再検証によって修正されない entity body または entity header の何らかの側面 (例えば entity body の非可逆圧縮) を記述する warning であり、成功した再検証の後でも削除してはならない (MUST NOT)。

code 自体の定義については 14.46 節参照。

HTTP/1.0 cache は、response 内のすべての Warning を、第一のカテゴリのものを削除せずにキャッシュする。HTTP/1.0 cache に渡される response 内の Warning は余分な warning-date フィールドを持つので、将来の HTTP/1.1 受信者が誤ってキャッシュされた Warning を信じることが防がれる。

Warning は warning テキストも持つ。そのテキストは任意の適切な自然言語 (おそらく client の Accept ヘッダに基づく) であってよく (MAY)、使用されている文字セットの OPTIONAL な指示を含んでもよい。

複数の warning を (origin server または cache のいずれかによって) response に付加してもよく (MAY)、同じ code 番号を持つ複数の warning を含めてもよい。例えば、server が同じ warning を英語とバスク語の両方のテキストで提供するかもしれない。

複数の warning が response に付加されている場合、それらすべてをユーザに表示することは実用的でも妥当でもないかもしれない。本バージョンの HTTP は、どの warning をどの順序で表示するかを決める厳密な優先順位規則を規定していないが、いくつかのヒューリスティックを示唆している。

13.1.3 Cache-control Mechanisms (キャッシュ制御メカニズム)

HTTP/1.1 における基本的なキャッシュメカニズム (server が指定する expiration time と validator) は、cache への暗黙の directive である。場合によっては、server または client が HTTP cache に明示的な directive を与える必要がある。この目的のために Cache-Control ヘッダを使う。

Cache-Control ヘッダにより、client または server は request または response のいずれかで各種の directive を伝達できる。これらの directive は通常、デフォルトのキャッシュアルゴリズムを上書きする。一般則として、header 値の間に明白な矛盾がある場合は、最も制限の強い解釈 (すなわち、意味的透過性を維持する可能性が最も高いもの) が適用される。しかし、場合によっては、cache-control directive が意味的透過性の近似を弱めるものとして明示的に指定される (例えば「max-stale」や「public」)。

cache-control directive の詳細は 14.9 節で述べる。

13.1.4 Explicit User Agent Warnings (明示的なユーザーエージェント警告)

多くの user agent は、ユーザが基本的なキャッシュメカニズムを上書きできるようにしている。例えば、user agent は、キャッシュされた entity (明示的に古いものも含めて) を決して検証しないようユーザが指定できるようにしているかもしれない。あるいは user agent が、すべての request に「Cache-Control: max-stale=3600」を習慣的に追加するかもしれない。user agent は、非透過的な動作、または異常に効果の低いキャッシュをもたらす動作のいずれをもデフォルトとしてはならない (SHOULD NOT) が、ユーザの明示的な操作によってそのように明示的に構成されてもよい (MAY)。

ユーザが基本的なキャッシュメカニズムを上書きした場合、user agent は、その結果として server の透過性要件を満たさないかもしれない情報が表示されるときは常に (特に、表示される entity が古いことが分かっている場合)、そのことをユーザに明示的に示すべきである (SHOULD)。プロトコルは通常、response が古いかどうかを user agent が判断できるようにしているので、この表示は実際にそうなったときにのみ表示すればよい。表示はダイアログボックスである必要はない; アイコン (例えば腐った魚の絵) やその他の指示でよい。

ユーザがキャッシュメカニズムを、cache の効果を異常に低下させるような方法で上書きした場合、user agent は、ユーザが誤って過剰な資源を消費したり過度の遅延に悩まされたりしないよう、この状態を継続的に示すべきである (SHOULD) (例えば燃えている通貨の絵を表示することによって)。

13.1.5 Exceptions to the Rules and Warnings (ルールと警告の例外)

場合によっては、cache の運用者が、client から要求されていないときでも古い response を返すように cache を構成することを選んでもよい (MAY)。この決定は軽々しく行うべきではないが、可用性または性能の理由から、特に cache が origin server への接続が貧弱な場合に必要になることがある。cache が古い response を返すときは常に、潜在的な問題があるかもしれないことを client software がユーザに警告できるよう、その旨を (Warning ヘッダを使って) 必ず示さなければならない (MUST)。

またこれにより、user agent は first-hand または新鮮な response を入手するための手段を講じることができる。この理由から、cache は、client が明示的に first-hand または新鮮な response を要求した場合、技術的またはポリシー上の理由で従うことが不可能でない限り、古い response を返すべきではない (SHOULD NOT)。

13.1.6 Client-controlled Behavior (クライアント制御の動作)

origin server (および程度は劣るが、response の age への寄与によって中間 cache) が expiration 情報の主要な源である一方で、場合によっては、client が、cache が validation なしに cached response を返すかどうかに関する cache の決定を制御する必要がある。client は、Cache-Control ヘッダのいくつかの directive を使ってこれを行う。

client の request は、未検証の response について受け入れようとする最大 age を指定してもよい (MAY); 値 0 を指定すると、cache にすべての response の再検証を強制する。client はまた、response が満了するまでの最小残り時間を指定してもよい (MAY)。これらの選択肢はいずれも cache の動作に対する制約を増やすので、cache の意味的透過性の近似をさらに緩めることはできない。

client はまた、ある最大の古さまでの範囲で、古い response を受け入れることを指定してもよい (MAY)。これは cache に対する制約を緩めるので、origin server が指定した意味的透過性の制約に違反するかもしれないが、切断状態での動作、または接続が貧弱な状況での高可用性を支えるために必要になることがある。

13.2 Expiration Model (有効期限モデル)

13.2.1 Server-Specified Expiration (サーバー指定の有効期限)

HTTP キャッシュは、cache が origin server への request を完全に回避できるときに最もよく機能する。request を回避する主要なメカニズムは、origin server が将来の明示的な expiration time を提供し、その response を後続の request を満たすために使ってもよい (MAY) ことを示すことである。言い換えれば、cache は server に最初に問い合わせることなく新鮮な response を返すことができる。

我々の期待は、server が、expiration time に達する前に entity が意味的に重要な形で変化する可能性は低いと信じて、response に将来の明示的な expiration time を割り当てるということである。これは、server の expiration time が注意深く選ばれている限り、通常は意味的透過性を保つ。

expiration メカニズムは、cache から取り出された response にのみ適用され、要求元 client に直ちに転送される first-hand response には適用されない。

origin server が、意味的に透過的な cache に毎回の request を検証させたい場合、過去の明示的な expiration time を割り当ててもよい (MAY)。これは response が常に古いことを意味するので、cache は後続の request に使う前にそれを検証すべきである (SHOULD)。再検証を強制するより制限の強い方法については 14.9.4 節参照。

origin server が、どのように構成されていようと任意の HTTP/1.1 cache に毎回の request を検証させたい場合、「must-revalidate」cache-control directive を使うべきである (SHOULD) (14.9 節参照)。

server は、Expires ヘッダか、Cache-Control ヘッダの max-age directive のいずれかを使って明示的な expiration time を指定する。

expiration time は、user agent に表示の更新やリソースの再読み込みを強制するために使うことはできない; その意味論はキャッシュメカニズムにのみ適用され、そのようなメカニズムは、そのリソースへの新しい request が開始されたときにのみリソースの expiration 状態を調べればよい。cache と履歴メカニズムの違いの説明については 13.13 節参照。

13.2.2 Heuristic Expiration (ヒューリスティック有効期限)

origin server が常に明示的な expiration time を提供するわけではないので、HTTP cache は通常、他の header 値 (Last-Modified time など) を使って妥当な expiration time を推定するアルゴリズムを使って、ヒューリスティックな expiration time を割り当てる。HTTP/1.1 仕様は特定のアルゴリズムを提供していないが、その結果に対する最悪の場合の制約を課している。ヒューリスティックな expiration time は意味的透過性を損なうかもしれないので、慎重に使うべきであり、我々は origin server ができるだけ明示的な expiration time を提供することを推奨する。

13.2.3 Age Calculations (経過時間計算)

cached entry が新鮮かどうかを知るために、cache はその age が freshness lifetime を超えているかどうかを知る必要がある。後者の計算方法は 13.2.4 節で論じる; 本節では response または cache entry の age を計算する方法を述べる。

この議論では、「now」という用語を「計算を行っている host の時計の現在値」の意味で使う。HTTP を使う host、特に origin server や cache を動かす host は、NTP [28] または同様のプロトコルを使って、その時計を世界的に正確な時刻標準に同期させるべきである (SHOULD)。

HTTP/1.1 は、origin server に、可能であればすべての response に Date ヘッダを付けて、response が生成された時刻を示すことを要求する (14.18 節参照)。我々は Date ヘッダの値を、算術演算に適した形で表すのに「date_value」という用語を使う。

HTTP/1.1 は、cache から得られたときの response message の推定 age を伝えるために Age response-header を使う。Age フィールド値は、response が origin server によって生成または再検証されてからの時間量についての cache の推定値である。

本質的に、Age 値は、response が origin server からの経路上の各 cache に滞留していた時間の合計に、ネットワーク経路上を転送中であった時間量を加えたものである。

我々は Age ヘッダの値を、算術演算に適した形で表すのに「age_value」という用語を使う。

response の age は、まったく独立した 2 つの方法で計算できる:

  1. ローカルクロックが origin server の時計と十分よく同期している場合は、now から date_value を引く。結果が負の場合、結果はゼロに置き換えられる。

  2. response 経路上のすべての cache が HTTP/1.1 を実装している場合は、age_value。

response を受け取ったときにその age を計算する独立した 2 つの方法があるので、これらを次のように組み合わせることができる:

       corrected_received_age = max(now - date_value, age_value)

そして、ほぼ同期した時計か、すべてが HTTP/1.1 の経路のいずれかを持っている限り、信頼できる (保守的な) 結果が得られる。

ネットワークによる遅延のため、server が response を生成した時刻と、それが次の outbound cache または client で受信される時刻との間に、かなりの間隔が生じることがある。修正しなければ、この遅延は不適切に低い age をもたらす可能性がある。

返された Age 値をもたらした request は、その Age 値の生成より前に開始されていたに違いないので、request が開始された時刻を記録することで、ネットワークによる遅延を修正できる。そして Age 値を受け取ったとき、それは response を受信した時刻ではなく request が開始された時刻を基準に解釈しなければならない (MUST)。このアルゴリズムは、どれほどの遅延を経験しても保守的な動作をもたらす。したがって次のように計算する:

      corrected_initial_age = corrected_received_age
                            + (now - request_time)

ここで「request_time」は、この response を引き出した request が送信された時刻 (ローカルクロックによる) である。

cache が response を受け取ったときの age 計算アルゴリズムの要約:

      /*
       * age_value
       *      is the value of Age: header received by the cache with
       *              this response.
       * date_value
       *      is the value of the origin server's Date: header
       * request_time
       *      is the (local) time when the cache made the request
       *              that resulted in this cached response
       * response_time
       *      is the (local) time when the cache received the
       *              response
       * now
       *      is the current (local) time
       */

      apparent_age = max(0, response_time - date_value);
      corrected_received_age = max(apparent_age, age_value);
      response_delay = response_time - request_time;
      corrected_initial_age = corrected_received_age + response_delay;
      resident_time = now - response_time;
      current_age   = corrected_initial_age + resident_time;

cache entry の current_age は、cache entry が最後に origin server によって検証されてからの時間量 (秒) を corrected_initial_age に加えることで計算される。response が cache entry から生成されるとき、cache は cache entry の current_age に等しい値を持つ単一の Age header field を response に含めなければならない (MUST)。

response に Age header field が存在することは、その response が first-hand でないことを意味する。しかし、その逆は成り立たない。response に Age header field がないことは、request 経路上のすべての cache が HTTP/1.1 に準拠していない限り、その response が first-hand であることを意味しないからである (すなわち、古い HTTP cache は Age header field を実装していなかった)。

13.2.4 Expiration Calculations (有効期限計算)

response が fresh か stale かを判断するために、その freshness lifetime と age を比較する必要がある。age は 13.2.3 節で述べたように計算される; 本節では freshness lifetime の計算方法と、response が満了したかどうかの判定方法を述べる。以下の議論では、値は算術演算に適した任意の形で表してよい。

我々は Expires ヘッダの値を表すのに「expires_value」という用語を使う。response 中の Cache-Control ヘッダの「max-age」directive が持つ秒数の適切な値を表すのに「max_age_value」という用語を使う (14.9.3 節参照)。

max-age directive は Expires より優先されるので、response に max-age が存在する場合、計算は単純に:

      freshness_lifetime = max_age_value

そうでなく、response に Expires が存在する場合、計算は:

      freshness_lifetime = expires_value - date_value

これらの計算はいずれもクロックのずれに対して脆弱ではないことに注意されたい。すべての情報が origin server から来るからである。

response に Expires、Cache-Control: max-age、または Cache-Control: s-maxage (14.9.3 節参照) のいずれも現れず、かつ response がキャッシュに関する他の制限を含まない場合、cache はヒューリスティックを使って freshness lifetime を計算してもよい (MAY)。cache は、age が 24 時間を超える response で、まだその warning が付加されていないものには、Warning 113 を付加しなければならない (MUST)。

また、response に Last-Modified time がある場合、ヒューリスティックな expiration 値は、その時刻以降の間隔の何分の一かを超えるべきではない (SHOULD)。この割合の典型的な設定は 10% であろう。

response が満了したかどうかを判定する計算はきわめて単純である:

      response_is_fresh = (freshness_lifetime > current_age)

13.2.5 Disambiguating Expiration Values (有効期限値の曖昧さ解消)

有効期限の値は楽観的に割り当てられるため、2 つの cache が同じ resource に対して異なる fresh な値を持つことがありうる。

retrieval を行っている client が、自分の cache ではすでに fresh であった request に対して非 first-hand response を受け取り、既存の cache entry の Date ヘッダが新しい response の Date より新しい場合、client はその response を無視してもよい (MAY)。その場合、origin server との確認を強制するために、「Cache-Control: max-age=0」directive (14.9 節参照) を付けて request を再試行してもよい (MAY)。

cache が同じ representation に対して異なる validator を持つ 2 つの fresh response を持っている場合、より新しい Date ヘッダを持つ方を使わなければならない (MUST)。この状況は、cache が他の cache からの response を集めているため、または client が明らかに fresh な cache entry の reload や revalidation を要求したために生じることがある。

13.2.6 Disambiguating Multiple Responses (複数のレスポンスの曖昧さ解消)

client が複数の経路で response を受け取ることがあり、ある response はある cache の集合を通り、他の response は別の cache の集合を通るため、client は origin server が送った順序とは異なる順序で response を受け取ることがある。我々は、古い response がまだ fresh に見えても、client に最も新しく生成された response を使ってほしい。

entity tag も expiration value も response に順序を課すことはできない。後の response が意図的に早い expiration time を持つ可能性があるからである。Date 値は 1 秒の粒度で順序付けられる。

client が cache entry を再検証しようとして、受け取った response に含まれる Date ヘッダが既存の entry のものより古いように見える場合、client は無条件に request を繰り返し、次を含めるべきである (SHOULD):

       Cache-Control: max-age=0

これは、任意の中間 cache にその副本を origin server と直接検証させるためであり、または次を含める:

       Cache-Control: no-cache

これは、任意の中間 cache に origin server から新しい副本を取得させるためである。

Date 値が等しい場合、client はどちらの response を使ってもよい (MAY) (あるいは、極度に慎重であるなら、新しい response を要求してもよい (MAY))。server は、同一秒の間に生成された response の expiration time が重なる場合、client がそれらの間で決定論的に選択できることに依存してはならない (MUST NOT)。

13.3 Validation Model (検証モデル)

cache が、client の request への response として使いたい stale な entry を持っている場合、まず origin server (または fresh な response を持つ中間 cache かもしれない) に問い合わせて、その cached entry がまだ使用可能かどうかを確認しなければならない。我々はこれを cache entry の「validating」と呼ぶ。cached entry が良好な場合に完全な response を再送信するオーバーヘッドを払いたくないし、cached entry が無効な場合に余分な往復のオーバーヘッドを払いたくもないので、HTTP/1.1 プロトコルは conditional method の使用をサポートしている。

conditional method をサポートするための鍵となるプロトコル機能は、「cache validator」に関するものである。origin server が完全な response を生成するとき、それに何らかの validator を付加し、それが cache entry とともに保持される。client (user agent または proxy cache) が、cache entry を持っている resource に対して conditional request を行うとき、関連する validator を request に含める。

server は次にその validator を entity の現在の validator と照合し、それらが一致する場合 (13.3.3 節参照)、特別な status code (通常は 304 (Not Modified)) を entity-body なしで返す。そうでなければ、完全な response (entity-body を含む) を返す。したがって、validator が一致すれば完全な response の送信を避けられ、一致しなければ余分な往復を避けられる。

HTTP/1.1 では、conditional request は同じ resource への通常の request とまったく同じに見えるが、method (通常は GET) を暗黙に conditional にする特別な header (validator を含む) を運ぶ点だけが異なる。

プロトコルは、cache を検証する条件の肯定形と否定形の両方を含む。すなわち、validator が一致する場合にのみ method を実行することも、validator がまったく一致しない場合にのみ実行することも要求できる。

  Note: validator を持たない response でも、cache-control directive によって明示的に禁止されていない限り、キャッシュして満了するまで cache から提供してよい。しかし、cache が entity の validator を持たない場合は conditional retrieval ができないので、満了後に更新できない。

13.3.1 Last-Modified Dates (最終変更日)

Last-Modified entity-header field value は、cache validator としてよく使われる。簡単に言えば、entity が Last-Modified 値以降に変更されていなければ、cache entry は有効とみなされる。

13.3.2 Entity Tag Cache Validators (エンティティタグキャッシュバリデータ)

ETag response-header field value (entity tag) は、「不透明な」cache validator を提供する。これは、変更日を保存するのが不便な状況、HTTP 日付値の 1 秒の分解能では不十分な状況、または origin server が変更日の使用から生じうる特定のパラドックスを避けたい状況において、より信頼性の高い検証を可能にするかもしれない。

Entity Tag は 3.11 節で述べる。entity tag とともに使う header は 14.19 節、14.24 節、14.26 節、および 14.44 節で述べる。

13.3.3 Weak and Strong Validators (弱いバリデータと強いバリデータ)

origin server と cache はどちらも、2 つの validator が同じ entity を表すか異なる entity を表すかを判断するために比較するので、通常は、entity (entity-body または任意の entity-header) が何らかの形で変化すれば、関連する validator も変化すると期待されるであろう。これが成り立つ場合、我々はその validator を「strong validator」と呼ぶ。

しかし、server が、entity の重要でない側面が変化したときではなく、意味的に重要な変化のときにのみ validator を変えたいと考える場合があるかもしれない。resource が変化しても常に変化するとは限らない validator は「weak validator」である。

Entity tag は通常「strong validator」であるが、プロトコルは entity tag を「weak」としてタグ付けするメカニズムを提供する。strong validator は、entity のビットが変化するたびに変化するものと考えてよい; 一方、weak value は entity の意味が変化するたびに変化する。あるいは、strong validator は特定の entity の識別子の一部であり、weak validator は意味的に等価な entity の集合の識別子の一部であると考えてもよい。

  Note: strong validator の一例は、entity が変更されるたびに安定した記憶域でインクリメントされる整数である。

  entity の変更時刻は、1 秒の分解能で表される場合、weak validator になりうる。resource が 1 秒の間に 2 回変更される可能性があるからである。

  weak validator のサポートは任意である。しかし、weak validator は等価なオブジェクトをより効率的にキャッシュできるようにする; 例えば、サイトのヒットカウンタは数日または数週間ごとに更新されればおそらく十分であり、その間のどの値も等価とみなすのに「十分」である可能性が高い。

validator の「使用」とは、client が request を生成して検証用の header field に validator を含めるとき、または server が 2 つの validator を比較するときのいずれかである。

Strong validator はどのような文脈でも使える。Weak validator は、entity の厳密な等価性に依存しない文脈でのみ使える。例えば、完全な entity の conditional GET にはどちらの種類も使える。しかし、サブレンジ取得には strong validator しか使えない。そうでないと、client が内部的に矛盾した entity を受け取る結果になりうるからである。

client は、weak validator または strong validator のいずれかを使って単純な (サブレンジでない) GET request を発行してもよい (MAY)。client は他の形の request では weak validator を使ってはならない (MUST NOT)。

HTTP/1.1 プロトコルが validator について定義する唯一の関数は比較である。比較の文脈が weak validator の使用を許すかどうかに応じて、2 つの validator 比較関数がある:

  - strong comparison function: 等しいとみなされるためには、両方の validator がすべての点で同一でなければならず (MUST)、かつ両方とも weak であってはならない (MUST NOT)。

  - weak comparison function: 等しいとみなされるためには、両方の validator がすべての点で同一でなければならない (MUST) が、いずれかまたは両方に「weak」というタグが付いていても結果に影響しない (MAY)。

entity tag は、明示的に weak とタグ付けされていない限り strong である。3.11 節が entity tag の構文を与える。

Last-Modified time は、request で validator として使われる場合、次の規則を使って strong であると推定できるのでない限り、暗黙に weak である:

  - validator が origin server によって entity の実際の現在の validator と比較されており、かつ

  - その origin server が、提示された validator が対象とする秒の間に、関連する entity が 2 回変化しなかったことを確実に知っている場合。

または

  - validator が、client が関連する entity の cache entry を持っているために、client によって If-Modified-Since または If-Unmodified-Since ヘッダで使われようとしており、かつ

  - その cache entry が Date 値を含み、それが origin server が元の response を送った時刻を与え、かつ

  - 提示された Last-Modified time が Date 値より少なくとも 60 秒前である場合。

または

  - validator が、中間 cache によって、その cache entry に entity 用に格納された validator と比較されており、かつ

  - その cache entry が Date 値を含み、それが origin server が元の response を送った時刻を与え、かつ

  - 提示された Last-Modified time が Date 値より少なくとも 60 秒前である場合。

この方法は、origin server が同じ秒の間に 2 つの異なる response を送ったが、両方が同じ Last-Modified time を持っていた場合、それらの response のうち少なくとも 1 つはその Last-Modified time に等しい Date 値を持つという事実に依拠している。任意の 60 秒という限界は、Date と Last-Modified の値が異なる時計から、あるいは response の準備中のやや異なる時刻に生成される可能性を防ぐものである。実装は、60 秒が短すぎると考えられる場合、60 秒より大きな値を使ってもよい (MAY)。

client が、opaque な validator を持たず Last-Modified time だけを持つ値に対してサブレンジ取得を行いたい場合、ここで述べた意味で Last-Modified time が strong である場合にのみそれを行ってもよい (MAY)。

完全な body の GET request 以外の conditional request を受け取った cache または origin server は、その条件を評価するために strong comparison function を使わなければならない (MUST)。

これらの規則により、HTTP/1.1 の cache と client は、HTTP/1.0 server から取得した値に対して安全にサブレンジ取得を行える。

13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates (エンティティタグと最終変更日を使用する場合のルール)

我々は、様々な種類の validator をいつ、どのような目的で使うべきかについて、origin server、client、および cache のための規則と推奨の集合を採用する。

HTTP/1.1 origin server:

  - entity tag validator を生成することが実行可能でない場合を除き、それを送るべきである (SHOULD)。

  - 性能上の考慮が weak entity tag の使用を支持する場合、または strong entity tag を送るのが実行不可能な場合、strong entity tag の代わりに weak entity tag を送ってもよい (MAY)。

  - 送ることが実行可能であれば Last-Modified 値を送るべきである (SHOULD) — ただし、この日付を If-Modified-Since ヘッダで使うことから生じうる意味的透過性の破綻の危険が深刻な問題を招く場合を除く。

言い換えれば、HTTP/1.1 origin server にとって望ましい動作は、strong entity tag と Last-Modified 値の両方を送ることである。

適法であるためには、strong entity tag は、関連する entity 値が何らかの形で変化するたびに変化しなければならない (MUST)。weak entity tag は、関連する entity が意味的に重要な形で変化するたびに変化すべきである (SHOULD)。

  Note: 意味的に透過的なキャッシュを提供するために、origin server は、特定の strong entity tag 値を 2 つの異なる entity に再利用したり、特定の weak entity tag 値を 2 つの意味的に異なる entity に再利用したりすることを避けなければならない。cache entry は expiration time にかかわらず任意の長期間持続しうるので、cache が過去のある時点で取得した validator を使って再び entry を検証しようとしないと期待するのは不適切かもしれない。

HTTP/1.1 client:

  - entity tag が origin server によって提供されている場合、(If-Match または If-None-Match を使う) 任意の cache-conditional request でその entity tag を使わなければならない (MUST)。

  - Last-Modified 値のみが origin server によって提供されている場合、(If-Modified-Since を使う) サブレンジでない cache-conditional request でその値を使うべきである (SHOULD)。

  - Last-Modified 値のみが HTTP/1.0 origin server によって提供されている場合、(If-Unmodified-Since を使う) サブレンジの cache-conditional request でその値を使ってもよい (MAY)。user agent は、問題が生じた場合に備えて、これを無効にする方法を提供すべきである (SHOULD)。

  - entity tag と Last-Modified 値の両方が origin server によって提供されている場合、cache-conditional request で両方の validator を使うべきである (SHOULD)。これにより、HTTP/1.0 と HTTP/1.1 の両方の cache が適切に応答できる。

HTTP/1.1 origin server は、cache validator として Last-Modified date (例えば If-Modified-Since または If-Unmodified-Since header field 内) と 1 つ以上の entity tag (例えば If-Match、If-None-Match、または If-Range header field 内) の両方を含む conditional request を受け取った場合、request 内のすべての conditional header field と整合しない限り、304 (Not Modified) の response status を返してはならない (MUST NOT)。

HTTP/1.1 caching proxy は、cache validator として Last-Modified date と 1 つ以上の entity tag の両方を含む conditional request を受け取った場合、その cached response が request 内のすべての conditional header field と整合しない限り、局所的にキャッシュされた response を client に返してはならない (MUST NOT)。

  Note: これらの規則の背後にある一般原則は、HTTP/1.1 の server と client は、自身の response と request で利用可能な冗長でない情報をできるだけ多く伝達すべきであるということである。この情報を受け取る HTTP/1.1 システムは、受け取った validator について最も保守的な仮定を行う。

  HTTP/1.0 の client と cache は entity tag を無視する。一般に、これらのシステムが受信または使用する last-modified 値は透過的で効率的なキャッシュを支えるので、HTTP/1.1 origin server は Last-Modified 値を提供すべきである。HTTP/1.0 システムが Last-Modified 値を validator として使うことが深刻な問題を招きうる稀な場合には、HTTP/1.1 origin server はそれを提供すべきでない。

13.3.5 Non-validating Conditionals (非検証条件)

entity tag の背後にある原則は、resource の意味論を十分よく理解して適切な cache validation メカニズムを選択できるのは service author だけであり、バイトの等価性より複雑な validator comparison function を規定すると厄介な問題を招くというものである。したがって、(HTTP/1.0 との互換性のために Last-Modified を除き) 他の header の比較が cache entry を検証する目的で使われることは決してない。

13.4 Response Cacheability (レスポンスのキャッシュ可能性)

cache-control (14.9 節) directive によって特に制約されない限り、caching system は successful response (13.8 節参照) を常に cache entry として格納してもよく (MAY)、それが fresh であれば検証なしに返してもよく (MAY)、成功した検証の後に返してもよい (MAY)。response に cache validator も明示的な expiration time も関連付けられていない場合、我々はそれがキャッシュされるとは期待しないが、特定の cache はこの期待に反するかもしれない (MAY) (例えばネットワーク接続がほとんどまたはまったくない場合)。client は通常、Date ヘッダを現在時刻と比較することで、そのような response が cache から取り出されたことを検出できる。

  Note: 一部の HTTP/1.0 cache は、Warning をまったく提供せずにこの期待に反することが知られている。

しかし、場合によっては、cache が entity を保持したり、後続の request への応答でそれを返したりすることが不適切なことがある。これは、service author が絶対的な意味的透過性を必要と判断したため、またはセキュリティやプライバシーの考慮によるかもしれない。したがって、server が、特定の resource entity またはその部分が他の考慮にかかわらずキャッシュされるべきでないことを示せるように、特定の cache-control directive が提供されている。

前の request が Authorization ヘッダを含んでいた場合、14.8 節が通常 shared cache によるその request への response の保存と返却を妨げることに注意されたい。

status code 200、203、206、300、301、または 410 で受け取った response は、cache-control directive がキャッシュを禁止していない限り、cache が格納し、expiration メカニズムに従って後続の request への応答に使ってもよい (MAY)。しかし、Range および Content-Range ヘッダをサポートしない cache は、206 (Partial Content) response をキャッシュしてはならない (MUST NOT)。

他の任意の status code (例えば status code 302 および 307) で受け取った response は、明示的に許可する cache-control directive または他の header がない限り、後続の request への応答で返してはならない (MUST NOT)。例えば、次のものが含まれる: Expires ヘッダ (14.21 節); 「max-age」、「s-maxage」、「must-revalidate」、「proxy-revalidate」、「public」、または「private」cache-control directive (14.9 節)。

13.5 Constructing Responses From Caches (キャッシュからのレスポンス構築)

HTTP cache の目的は、request への応答で受け取った情報を、将来の request への応答で使うために格納することである。多くの場合、cache は単に response の適切な部分を要求者に返す。しかし、cache が以前の response に基づく cache entry を保持している場合、新しい response の部分を cache entry に保持されているものと組み合わせなければならないことがある。

13.5.1 End-to-end and Hop-by-hop Headers (エンドツーエンドヘッダとホップバイホップヘッダ)

cache と非キャッシュ proxy の動作を定義する目的で、我々は HTTP ヘッダを 2 つのカテゴリに分ける:

  - End-to-end ヘッダ: request または response の最終受信者へ伝達されるもの。response 内の end-to-end ヘッダは cache entry の一部として格納しなければならず (MUST)、cache entry から形成される任意の response で伝達しなければならない (MUST)。

  - Hop-by-hop ヘッダ: 単一のトランスポートレベル接続に対してのみ意味を持ち、cache によって格納されず、proxy によって転送されないもの。

次の HTTP/1.1 ヘッダは hop-by-hop ヘッダである:

  - Connection
  - Keep-Alive
  - Proxy-Authenticate
  - Proxy-Authorization
  - TE
  - Trailers
  - Transfer-Encoding
  - Upgrade

HTTP/1.1 によって定義される他のすべてのヘッダは end-to-end ヘッダである。

他の hop-by-hop ヘッダは、HTTP/1.1 (またはそれ以降) に導入されるために Connection ヘッダ (14.10 節) に列挙されなければならない (MUST)。

13.5.2 Non-modifiable Headers (変更不可能なヘッダ)

Digest Authentication のような HTTP/1.1 プロトコルの一部の機能は、特定の end-to-end ヘッダの値に依存する。transparent proxy は、そのヘッダの定義が要求または明示的に許容しない限り、end-to-end ヘッダを変更すべきではない (SHOULD NOT)。

transparent proxy は、request または response 内の次の field を変更してはならず (MUST NOT)、まだ存在しない場合はこれらの field を追加してもならない:

  - Content-Location

  - Content-MD5

  - ETag

  - Last-Modified

transparent proxy は、response 内の次の field を変更してはならない (MUST NOT):

  - Expires

ただし、まだ存在しない場合はこれらの field を追加してもよい (MAY)。Expires ヘッダを追加する場合、その response 内の Date ヘッダと同一の field-value を与えなければならない (MUST)。

proxy は、no-transform cache-control directive を含む message 内、または任意の request 内で、次の field を変更または追加してはならない (MUST NOT):

  - Content-Encoding

  - Content-Range

  - Content-Type

non-transparent proxy は、no-transform を含まない message にこれらの field を変更または追加してもよい (MAY) が、そうする場合は、その message 内にまだ現れていなければ Warning 214 (Transformation applied) を追加しなければならない (MUST) (14.46 節参照)。

      Warning: unnecessary modification of end-to-end headers might
      cause authentication failures if stronger authentication
      mechanisms are introduced in later versions of HTTP. Such
      authentication mechanisms MAY rely on the values of header fields
      not listed here.

request または response の Content-Length field は、4.4 節の規則に従って追加または削除される。transparent proxy は、entity-body の entity-length (7.2.2 節) を保持しなければならない (MUST) が、transfer-length (4.4 節) を変更してもよい (MAY)。

13.5.3 Combining Headers (ヘッダの結合)

cache が server に対して validating request を行い、server が 304 (Not Modified) response または 206 (Partial Content) response を提供すると、cache は要求元 client に送る response を構築する。

status code が 304 (Not Modified) の場合、cache は cache entry に格納された entity-body を、この外向き response の entity-body として使う。status code が 206 (Partial Content) で、ETag または Last-Modified ヘッダが正確に一致する場合、cache は cache entry に格納された内容と response で受け取った新しい内容を組み合わせ、その結果をこの外向き response の entity-body として使ってもよい (MAY) (13.5.4 節参照)。

cache entry に格納された end-to-end ヘッダが、構築される response に使われる。ただし次の場合を除く:

  - warn-code 1xx (14.46 節参照) を持つ格納された Warning ヘッダは、cache entry および転送される response から削除しなければならない (MUST)。

  - warn-code 2xx を持つ格納された Warning ヘッダは、cache entry および転送される response に保持しなければならない (MUST)。

  - 304 または 206 response で提供される end-to-end ヘッダは、cache entry からの対応するヘッダを置き換えなければならない (MUST)。

cache が cache entry を削除することを決めない限り、cache はまた、cache entry とともに格納された end-to-end ヘッダを、すぐ上で述べた Warning ヘッダを除いて、受信 response で受け取った対応するヘッダで置き換えなければならない (MUST)。受信 response 内の header field-name が cache entry 内の複数のヘッダに一致する場合、そのような古いヘッダはすべて置き換えなければならない (MUST)。

言い換えれば、受信 response で受け取った end-to-end ヘッダの集合は、cache entry とともに格納された対応するすべての end-to-end ヘッダを上書きする (warn-code 1xx を持つ格納された Warning ヘッダは、上書きされなくても削除される)。

  Note: この規則により、origin server は 304 (Not Modified) または 206 (Partial Content) response を使って、同一 entity またはその sub-range に対する以前の response に関連する任意のヘッダを更新できる — ただし、そうすることが常に有意義または正確であるとは限らない。この規則は、origin server が 304 (Not Modified) または 206 (Partial Content) response を使って、以前の response で提供したヘッダを完全に削除することを許すものではない。

13.5.4 Combining Byte Ranges (バイト範囲の結合)

response は、request が 1 つ以上の Range specification を含んでいたため、または connection が途中で切断されたために、entity-body のバイトの部分範囲のみを転送することがある。そのような転送が数回あると、cache は同じ entity-body の複数の range を受け取っていることがある。

cache が entity について空でない subrange の集合を格納しており、受信 response が別の subrange を転送する場合、cache は次の両方の条件が満たされるときに新しい subrange を既存の集合と組み合わせてもよい (MAY):

  - 受信 response と cache entry の両方が cache validator を持つ。

  - 2 つの cache validator が strong comparison function を使って一致する (13.3.3 節参照)。

いずれかの要件が満たされない場合、cache は (すべての response とともに伝達される Date 値に基づき、それらの値が等しいか欠けている場合は受信 response を使って) 最も新しい partial response のみを使わなければならず (MUST)、他の partial information を破棄しなければならない (MUST)。

13.6 Caching Negotiated Responses (ネゴシエートされたレスポンスのキャッシング)

response に Vary header field が存在することによって示されるように server-driven content negotiation (12.1 節) を使うと、cache がその response を後続の request に使う際の条件と手順が変わる。server による Vary header field の使用については 14.44 節参照。

server は、server-driven negotiation の対象となる cacheable response の複数の representation の中から選択するためにどの request-header field を使ったかを cache に知らせるために、Vary header field を使うべきである (SHOULD)。Vary field value が命名する header field の集合は「selecting」request-header として知られている。

cache が、Request-URI が Vary header field を含む 1 つ以上の cache entry を指定する後続の request を受け取った場合、cache は、新しい request に存在するすべての selecting request-header が元の request 内の対応する格納された request-header と一致しない限り、そのような cache entry を使って新しい request への response を構築してはならない (MUST NOT)。

2 つの request の selecting request-header は、第一の request の selecting request-header が、対応する BNF で許される場所に線形空白 (LWS) を追加または削除することによって、および/または 4.2 節の message header に関する規則に従って同じ field name を持つ複数の message-header field を結合することによって、第二の request の selecting request-header に変換できる場合に限り、一致すると定義される。

Vary header field-value が「*」の場合は常に一致に失敗し、その resource への後続の request は origin server によってのみ正しく解釈できる。

格納された entry の selecting request header field が新しい request の selecting request header field と一致しない場合、cache は、まず新しい request を conditional request として origin server に中継し、server が 304 (Not Modified) で応答して、使用すべき entity を示す entity tag または Content-Location を含めるのでない限り、格納された entry を request の充足に使ってはならない (MUST NOT)。

格納された representation に entity tag が割り当てられていた場合、転送される request は conditional であるべきであり (SHOULD)、その resource に対するすべての cache entry からの entity tag を If-None-Match header field に含めるべきである。これは、cache が現在保持している entity の集合を server に伝えるので、これらの entity のいずれかが要求された entity と一致すれば、server は 304 (Not Modified) response 内の ETag header field を使って、どの entry が適切かを cache に伝えられる。新しい response の entity-tag が既存の entry のものと一致する場合、新しい response を既存の entry の header field の更新に使うべきであり (SHOULD)、その結果を client に返さなければならない (MUST)。

既存の cache entry のいずれかが関連する entity について部分的な内容しか含まない場合、その entity-tag は、request がその entry で完全に満たされる range を求めるものでない限り、If-None-Match header field に含めるべきではない (SHOULD NOT)。

cache が、Content-Location field が同じ Request-URI に対する既存の cache entry のものと一致し、entity-tag が既存の entry のものと異なり、Date が既存の entry のものより新しい successful response を受け取った場合、既存の entry は将来の request への応答で返すべきではなく (SHOULD NOT)、cache から削除すべきである (SHOULD)。

13.7 Shared and Non-Shared Caches (共有キャッシュと非共有キャッシュ)

セキュリティとプライバシーの理由から、「shared」cache と「non-shared」cache を区別する必要がある。non-shared cache とは、単一のユーザのみがアクセスできるものである。この場合のアクセス可能性は、適切なセキュリティメカニズムによって強制されるべきである (SHOULD)。他のすべての cache は「shared」とみなされる。本仕様の他の節は、プライバシーの喪失やアクセス制御の失敗を防ぐために、shared cache の動作に一定の制約を課している。

13.8 Errors or Incomplete Response Cache Behavior (エラーまたは不完全なレスポンスキャッシュの動作)

不完全な response (例えば Content-Length ヘッダで指定されたより少ないデータバイト) を受け取った cache は、その response を格納してもよい (MAY)。しかし、cache はこれを partial response として扱わなければならない (MUST)。partial response は 13.5.4 節で述べたように組み合わせてもよく (MAY)、その結果は完全な response になることも、依然として部分的なままであることもある。cache は、206 (Partial Content) status code を使って明示的にそのように示すことなく、partial response を client に返してはならない (MUST NOT)。cache は、status code 200 (OK) を使って partial response を返してはならない (MUST NOT)。

cache が entry を再検証しようとしている間に 5xx response を受け取った場合、この response を要求元 client に転送してもよく (MAY)、server が応答に失敗したかのように振る舞ってもよい (MAY)。後者の場合、cached entry が「must-revalidate」cache-control directive を含んでいない限り、以前に受け取った response を返してもよい (MAY) (14.9 節参照)。

13.9 Side Effects of GET and HEAD (GETとHEADの副作用)

origin server がそれらの response のキャッシュを明示的に禁止しない限り、任意の resource への GET および HEAD method の適用は、それらの response が cache から取り出された場合に誤った動作を招くような副作用を持たないべきである (SHOULD NOT)。それらは依然として副作用を持ちうるが、cache はそのような副作用をキャッシュの判断で考慮することを要求されない。cache は常に、origin server の明示的なキャッシュ制限を守ることが期待される。

我々はこの規則に 1 つの例外があることに注意する: 一部の application が伝統的に、query URL (rel_path 部分に「?」を含むもの) を伴う GET や HEAD を使って有意な副作用を持つ操作を行ってきたため、cache は、server が明示的な expiration time を提供しない限り、そのような URI への response を fresh として扱ってはならない (MUST NOT)。これは特に、そのような URI に対する HTTP/1.0 server からの response を cache から取り出すべきではない (SHOULD NOT) ことを意味する。関連情報については 9.1.1 節参照。

13.10 Invalidation After Updates or Deletions (更新または削除後の無効化)

origin server のある resource に対して行われる特定の method の効果により、1 つ以上の既存の cache entry が非透過的に無効になることがある。すなわち、それらは「fresh」であり続けるかもしれないが、その resource への新しい request に対して origin server が返すであろうものを正確に反映していない。

HTTP プロトコルには、そのようなすべての cache entry が無効として印付けされることを保証する方法はない。例えば、origin server での変更を引き起こした request が、cache entry が格納されている proxy を通らなかったかもしれない。しかし、いくつかの規則が誤った動作の可能性を減らす助けになる。

本節で「entity を invalidate する」という語句は、cache がその entity のすべての instance をその記憶域から削除するか、それらを「invalid」として印付け、後続の request への応答で返す前に必須の再検証を要するものとすることを意味する。

一部の HTTP method は、cache に entity を invalidate させなければならない (MUST)。これは Request-URI によって参照される entity、または Location もしくは Content-Location ヘッダ (存在する場合) によって参照される entity である。これらの method は:

  - PUT

  - DELETE

  - POST

サービス拒否攻撃を防ぐために、Location または Content-Location ヘッダ内の URI に基づく invalidation は、host 部分が Request-URI 内のものと同じである場合にのみ行わなければならない (MUST)。

理解しない method の request を通過させる cache は、Request-URI によって参照される任意の entity を invalidate すべきである (SHOULD)。

13.11 Write-Through Mandatory (書き込み貫通必須)

origin server の resource への変更を引き起こすと予想されうるすべての method は、origin server へ書き込み貫通 (write-through) しなければならない (MUST)。これは現在、GET および HEAD を除くすべての method を含む。cache は、そのような request を inbound server に伝達し、inbound server から対応する response を受け取る前に、client からの request に応答してはならない (MUST NOT)。これは、inbound server が最終的な返答を送る前に proxy cache が 100 (Continue) response を送ることを妨げるものではない。

(「write-back」または「copy-back」caching として知られる) 代替手段は、一貫した更新を提供することの難しさ、および write-back 前の server、cache、または network の障害から生じる問題のために、HTTP/1.1 では許されない。

13.12 Cache Replacement (キャッシュ置換)

resource について、同じ resource の既存の response がキャッシュされている間に、新しい cacheable な (14.9.2 節、13.2.5 節、13.2.6 節、および 13.8 節参照) response を受け取った場合、cache は、現在の request への返答に新しい response を使うべきである (SHOULD)。cache はそれを cache storage に挿入してもよく (MAY)、他のすべての要件を満たすなら、以前なら古い response を返させていたであろう将来の request への応答にそれを使ってもよい (MAY)。新しい response を cache storage に挿入する場合、13.5.3 節の規則が適用される。

  Note: 既存のキャッシュされた response より古い Date ヘッダ値を持つ新しい response は cacheable ではない。

13.13 History Lists (履歴リスト)

user agent はしばしば、「戻る」ボタンや履歴リストのような history メカニズムを持ち、それを使ってセッション中に以前に取得された entity を再表示できる。

history メカニズムと cache は異なる。特に、history メカニズムは、resource の現在の状態を意味的に透過的に表示しようとすべきではない (SHOULD NOT)。むしろ、history メカニズムは、resource が取得された時点でユーザが実際に見たものをそのまま示すためのものである。

デフォルトでは、expiration time は history メカニズムには適用されない。entity がまだ記憶域にある場合、history メカニズムは、ユーザが明示的に、満了した history document を更新するよう agent を構成していない限り、entity が満了していてもそれを表示すべきである (SHOULD)。

これは、history メカニズムが、ある表示が古いかもしれないことをユーザに伝えることを禁じるものと解釈されてはならない。

  Note: history list メカニズムが、ユーザが古い resource を表示するのを不必要に妨げる場合、これは service author が、本来なら使いたいと思うときに HTTP の expiration control や cache control を使わないように強いがちになる。service author は、ユーザが (BACK のような) ナビゲーション制御を使って以前に取得した resource を表示するときに、error message や warning message を提示されないことが重要だと考えるかもしれない。そのような resource はキャッシュされるべきでない、あるいはすぐに満了すべきであることもあるが、ユーザインタフェース上の考慮から、service author は、正しく機能しない history メカニズムの影響を受けないように、キャッシュを防ぐ他の手段 (例えば「once-only」URL) に頼らざるを得なくなることがある。