[4] キャッシュが応答メッセージの複製を蓄積して以後の要求に答えるために使うことが認められている時、 その応答はキャッシュ可か能のうcacheableであるといいます >>3。

[5] ただしキャッシュ可能であるからといっていつでもその応答を使いまわせるわけではなく、 要求が色々な条件を満たす必要があります。

[26] 本項ではキャッシュに蓄積された (キャッシュ項目に含まれる) 応答を再利用する (類似した新しい要求への応答として使う) 条件についても扱います。

[13] キャッシュ可能な応答であっても、キャッシュがそれを蓄積し再利用することは義務ではありません。 キャッシュ不可能な応答をキャッシュすることは禁止されていますが、 キャッシュ可能な応答がキャッシュされて再利用されるかどうかは、 実装方法、設定、ディスク容量その他色々な状況に依存します。

仕様書

キャッシュ可能メソッド

[7] 応答をキャッシュして再利用できるメソッドのことを、 キャッシュ可能cacheableであるといいます >>6。

[8] 次のメソッドは、キャッシュ可能です >>6。

[63] これらの状態符号でも、 Cache-Control: などの条件によってキャッシュできないことがあります。

キャッシュ可能な応答の状態符号

[11] 次の状態符号の応答はキャッシュ可能です。

[12] これらの状態符号でも、 Cache-Control: など他の条件によりキャッシュできないことがあります。

[10] 未知の状態符号の応答は、キャッシュしてはなりません >>9。

[62] >>61 の JSON ファイルに状態符号がキャッシュ可能かどうかの情報が含まれています。
  • [61] data-web-defs/http-status-codes.txt at master · manakai/data-web-defs ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/http-status-codes.txt

キャッシュ可能性の判定

[15] 応答を蓄積しても構わないかどうかは、次のように決定します。

  1. [16] 要求メソッドをキャッシュが理解しないなら、 蓄積できません >>14。ここで終わります。
  2. [17] 要求メソッドがキャッシュ可能でないなら、 蓄積できません >>14。ここで終わります。
  3. [18] 応答の状態符号をキャッシュが理解しないなら、 蓄積できません >>14。ここで終わります。
  4. [68] EventSource のための fetch であれば、 蓄積するべきではありません >>67。ここで終わります。
  5. [19] 要求の Cache-Control: ヘッダーに no-store キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。
  6. [66] 応答の Cache-Control: ヘッダーに no-store キャッシュ指示子があり >>14、 Cache-Control: im が適用されないなら >>65、蓄積できません。ここで終わります。
  7. [22] 共有キャッシュの場合、
    1. [20] 応答の Cache-Control: ヘッダーに引数なしの >>52 private キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。
    2. [34] 応答の Cache-Control: ヘッダーに public か s-maxage のキャッシュ指示子があれば、蓄積できます >>14, >>23。ここで終わります。
    3. [21] 要求に Authorization: ヘッダーがあって 応答の Cache-Control: ヘッダーに must-revalidate キャッシュ指示子がなければ、 蓄積できません >>14, >>23。ここで終わります。
  8. [35] 応答が Expires: ヘッダーを持つなら、蓄積できます >>14。ここで終わります。
  9. [24] 応答の Cache-Control: ヘッダーが max-age か public のキャッシュ指令を持つなら、蓄積できます >>14。ここで終わります。
  10. [54] 私的キャッシュの場合、
    1. [53] 応答の Cache-Control: ヘッダーが private キャッシュ指令を持つなら、 蓄積できます >>52。
  11. [25] 応答がキャッシュ可能な状態符号を持つなら、蓄積できます >>14。 ここで終わります。
  12. [31] 蓄積できません。

[32] これらの条件は、将来新たに規定されるキャッシュ指示子により上書きできます >>14。

[33] ここで「理解」とは、認識しすべてのキャッシュに関係する動作を実装していることをいいます >>14。

[43] これは蓄積して良い条件であり、しなければならないわけではありません。 キャッシュはより限定された条件でのみ蓄積して構いません。

[44] 例えばキャッシュはより簡易的に実装するために Cache-Control: no-cache の応答を一切蓄積しないことにしても構いません。 (>>40 の検証の実装を省けます。)

[50] ただし 304 応答によってヘッダーが更新される場合 (条件付き要求参照。) があるなど、蓄積された応答が蓄積後に変更される可能性がありますから、 そのような蓄積された応答を破棄したり、無視したりする処理は検証のかわりに必要となります。[56] Proxy-Authorization: はキャッシュ可能性に影響しないようです。

[58] HTTP/0.9 応答には状態符号を明示できないため、 キャッシュ不可能として扱うべきと思われます。

[64] 差分符号化に関して、 Cache-Control: retain の有無がキャッシュを蓄積するべきかのヒントを表しています。

retain を参照。

[69] OAuth 1.0 で Authorization: を使わない場合、 WSSE、その他独自の認証方式を使う場合には、 HTTPキャッシュがキャッシュ可能と判断する条件を満たしてしまうことがよくあります。 そのような認証方式を使うクライアントや鯖は、 Cache-Control: などで明示的にキャッシュ不可能と指定する必要があります。

キャッシュの再利用

[28] キャッシュは、次の条件をすべて満たす時に、 要求に対してキャッシュ項目の応答を再利用できます >>27。

[60] 透過内容折衝に対応するキャッシュは、リスト応答に関して Vary: の条件を無視できます >>59 (リスト応答を参照)。

[45] これらの条件は、新たなキャッシュ指示子により上書きできます >>27。

[47] 安全でないメソッドの要求にキャッシュが返答することはできず、 上流に転送しなければなりません。

[48] 候補が複数ある時は、最も新しいもの (Date: が最新のもの) を使わなければなりません。あるいは Cache-Control: max-age=0 または Cache-Control: no-cache をつけて転送しても構いません。 >>27

検証も参照。

[49] 時計を持たないキャッシュは、毎回検証しなければ蓄積された応答を使ってはなりません >>27。

[42] これは再利用して良い条件であり、しなければならないわけではありません。 キャッシュはより限定された条件でのみ再利用しても構いません。[46] 再利用については Age: も参照。[51] Cache-Control: max-age, max-stale, min-fresh, must-revalidate, proxy-revalidate も参照。[55] キャッシュ項目も参照。[57] ここでいう「再利用」は、 Meter: ヘッダーの処理における 「利用」や「再利用」とは意味が異なります。

歴史

HTTP/1.1

[2] RFC 2068 は cachable と綴っていましたが、 RFC 2616 以降は cacheable とされています。

[1] HTTP (RFC 2068 1.3, RFC 2616 1.3)
cacheable
A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
キャッシュ可能
応答は、キャッシュが以後の要求に回答するのに使うためにその応答メッセージの複製を蓄積することが許されているなら、 キャッシュ可能です。 HTTP 応答のキャッシュ可能性を決定する規則は13章で定義されています。 応答がキャッシュ可能であっても、特定の要求にキャッシュされた複製を使うことができるかどうかには更なる制約があるかもしれません。

[70] Spelling of "cachable" ( (Jeffrey Mogul著, )) https://lists.w3.org/Archives/Public/ietf-http-wg-old/1997SepDec/0003.html

内容折衝

[71] 内容折衝とキャッシュとの関係について。

[72] RFC 2068・RFC 2616 (HTTP/1.1) 13.6 Caching Negotiated Responses

Use of server-driven content negotiation (section 12.1.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers.

サーバー駆動内容折衝の使用は応答の Vary 頭欄の存在によって示されますが、 このときキャッシュが以後の要求にその応答を使用できる条件と手続きが変わります。

A server MUST SHOULD use the Vary header field (section 14.43) to inform a cache of what request-header fields dimensions are were used to select among multiple representations of a cacheable response subject to server-driven negotiation. A cache may use the selected representation (the entity included with that particular response) for replying to subsequent requests on that resource only when the subsequent requests have the same or equivalent values for all header fields specified in the Vary response-header. Requests with a different value for one or more of those header fields would be forwarded toward the origin server. The set of header fields named by the Vary field value is known as the "selecting" request-headers.

サーバーは、サーバー駆動折衝の対象となるキャッシュ可能な応答の複数の表現から選択するのにどの要求頭欄が使われるかをキャッシュに知らせるのに Vary 頭欄を使用しなければなりませんするべきです。 キャッシュは、その資源についての以後の要求に返答するのに、その以後の要求が Vary 応答頭欄に指定されたすべての頭欄で同じ又は同等の値を取っているときに限って選択された表現 (その特定の応答に含まれていた実体) を使っても構いません。幾つかの頭欄で異なる値を取っていた要求は起源サーバーに転送されることになります。 Vary 欄値に名前の挙げられている頭欄の集合は「選択」要求頭と呼びます。

When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.

キャッシュがその Request-URI が Vary 頭欄を含んだ1個か複数個のキャッシュ項目を示した以降の要求を受取った時には、 新しい要求にある選択要求頭の全てが対応する蓄積されている元の要求の要求頭欄に一致しない限り、そのキャッシュ項目を応答を構築するのに使ってはなりません。

The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.

2つの要求の選択要求頭は、最初の要求の選択要求頭に、対応する BNF で認められている場所に線形空白 (LWS) を追加したり削除したりすること及び/又は4.2節のメッセージ頭についての規則にしたがって同じ欄名の複数のメッセージ頭欄を結合することによって2番目の要求の選択要求頭欄に変形することができるなら、 この場合に限って、一致すると定義します。

A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.

Vary 頭欄の値 * は、 常に一致に失敗し、その資源についての後続の要求は期限サーバーのみが適切に解釈することができます。

If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used.

キャッシュ項目の選択要求頭欄が新しい要求の選択要求頭欄に一致しなかった場合、 キャッシュはまず新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は Content-Location を含んだ 304 (未修正) でサーバーが応答してこない限り、そのキャッシュ項目を後続の要求を満足させるために使ってはなりません。

If an entity tag was assigned to the a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the Request-URI resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.

実体札がキャッシュされた表現に割当てられていた場合、転送する要求は条件的であって、 その Request-URI 資源についての全てのキャッシュ項目の実体札を If-None-Match 頭欄に含めるべきです。 これはキャッシュが現在保持している実体の集合をサーバーに伝達し、 その項目のどれかが要求された実体に一致する場合には、 サーバーは 304 (未修正) 応答で ETag 頭を使ってどの項目が適当かキャッシュに教えることができます。 新しい応答の entity-tag が既存の項目の実体札と一致する場合には、 新しい応答を既存の項目の頭欄を更新するのに使うべきで、 その結果はクライアントに返さなければなりません。

The Vary header field may also inform the cache that the representation was selected using criteria not limited to the request-headers; in this case, a cache MUST NOT use the response in a reply to a subsequent request unless the cache relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates which entity should be used.

Vary 頭欄は、要求頭欄に限定されない基準を使って表現を選択したことをキャッシュに知らせることもできます。 この場合、キャッシュは新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は Content-Location を含んだ 304 (未修正) でサーバーが応答してこない限り、その応答を後続の要求で使ってはなりません。

If any of the existing cache entries contains only partial content for the associated entity, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry.

既存のキャッシュ項目のどれかが関連付けられた実体の部分内容だけしか含んでいない時には、 その要求がその項目で完全に満足できる範囲である場合を除いて、 その項目の entity-tag を If-None-Match 頭欄に含めるべきではありません。

If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same Request-URI Request-]URI (ママ), whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD NOT be returned in response to future requests, and should SHOULD be deleted from the cache.

キャッシュが成功応答を受取り、その Content-Location 欄が同じ Request-URI の既存のキャッシュ項目のものと一致し、 その entity-tag は既存の項目のものとは異なり、 その Date は既存の項目のものよりは新しい場合には、 その既存の項目は将来の要求に対する応答では返すべきではなく、 キャッシュから削除するべきです。

メモ