[4] キャッシュが応答メッセージの複製を蓄積して以後の要求に答えるために使うことが認められている時、 その応答はキャッシュ可能であるといいます >>3。
[26] 本項ではキャッシュに蓄積された (キャッシュ項目に含まれる) 応答を再利用する (類似した新しい要求への応答として使う) 条件についても扱います。
[7] 応答をキャッシュして再利用できるメソッドのことを、 キャッシュ可能であるといいます >>6。
[15] 応答を蓄積しても構わないかどうかは、次のように決定します。
EventSource のための fetch であれば、
蓄積するべきではありません >>67。ここで終わります。Cache-Control:
ヘッダーに no-store
キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。Cache-Control:
ヘッダーに no-store
キャッシュ指示子があり >>14、 Cache-Control: im
が適用されないなら >>65、蓄積できません。ここで終わります。Expires: ヘッダーを持つなら、蓄積できます
>>14。ここで終わります。Cache-Control: ヘッダーが
max-age か public
のキャッシュ指令を持つなら、蓄積できます >>14。ここで終わります。[33] ここで「理解」とは、認識しすべてのキャッシュに関係する動作を実装していることをいいます >>14。
[58] HTTP/0.9 応答には状態符号を明示できないため、 キャッシュ不可能として扱うべきと思われます。
[64] 差分符号化に関して、 Cache-Control: retain
の有無がキャッシュを蓄積するべきかのヒントを表しています。
retain を参照。[69] OAuth 1.0 で Authorization: を使わない場合、
WSSE、その他独自の認証方式を使う場合には、
HTTPキャッシュがキャッシュ可能と判断する条件を満たしてしまうことがよくあります。
そのような認証方式を使うクライアントや鯖は、
Cache-Control: などで明示的にキャッシュ不可能と指定する必要があります。
[28] キャッシュは、次の条件をすべて満たす時に、 要求に対してキャッシュ項目の応答を再利用できます >>27。
[60] 透過内容折衝に対応するキャッシュは、リスト応答に関して
Vary: の条件を無視できます >>59 (リスト応答を参照)。
[48] 候補が複数ある時は、最も新しいもの (Date:
が最新のもの) を使わなければなりません。あるいは
Cache-Control: max-age=0 または
Cache-Control: no-cache をつけて転送しても構いません。 >>27
[2] RFC 2068 は cachable と綴っていましたが、 RFC 2616 以降は cacheable とされています。
- 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.
[70] Spelling of "cachable" ( (Jeffrey Mogul著, )) https://lists.w3.org/Archives/Public/ietf-http-wg-old/1997SepDec/0003.html
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
MUSTSHOULD use the Vary header field(section 14.43)to inform a cache of what request-header fieldsdimensionsarewere 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
thea 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 theRequest-URIresource. 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-URIIf-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-URIRequest-]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,andshouldSHOULD be deleted from the cache.
キャッシュが成功応答を受取り、その Content-Location
欄が同じ Request-URI の既存のキャッシュ項目のものと一致し、
その entity-tag は既存の項目のものとは異なり、
その Date は既存の項目のものよりは新しい場合には、
その既存の項目は将来の要求に対する応答では返すべきではなく、
キャッシュから削除するべきです。