[34] [DFN[[CODE(HTTP)@en[[[Cache-Control:]]]]]] [[ヘッダー]]は、 [[キャッシュ]]における[[要求]]と[[応答]]の処理方法を指定するものです。 * 仕様書 [REFS[ - [19] '''[CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) ''' -- [40] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [49] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [57] [CITE[UPnP Device Architecture 2.0]] ([TIME[2014-09-05 02:24:48 +09:00]] 版) - [46] [CITE[Hypertext Transfer Protocol (HTTP) Cache Directive Registry]] ([TIME[2014-06-11 21:53:48 +09:00]] 版) - [59] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2014-12-04 10:25:09 +09:00]] 版) ]REFS] * 意味 [20] [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]は、 [[キャッシュ]]に対する[[指令]] ([DFN[[RUBYB[キャッシュ指令]@en[cache directive]]]]) を指定するものです [SRC[>>19]]。 ;; [37] ただし、[[キャッシュ]]を有しない[[中間器]]にも適用される[[キャッシュ指令]]もあります。 [21] この[[ヘッダー]]は[[要求]]でも[[応答]]でも利用できます。 この[[ヘッダー]]に指定する[[指令]]は、[[要求]]で用いるもの、 [[応答]]で用いるもの、どちらでも用いるものがあります。 しかしいずれにせよ[[指令]]は一方向的なものですから、 [[要求]]で指定されていたとしても、[[応答]]でも同じ[[指令]]が適用されることを意味しません [SRC[>>19]]。 ;; [45] 同じ[[キャッシュ指令]]でも[[要求]]と[[応答]]で[[引数]]の構文が異なることがあります。 * 構文 [29] [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]の値は、 1つ以上の[[キャッシュ指令]]の[[リスト]] ([CODE(HTTP)[#]]) です [SRC[>>19]]。 [FIG(railroad)[ = [[キャッシュ指令]] = * == [[OWS]] == [CODE(HTTP)[[[,]]]] == [[OWS]] == [[キャッシュ指令]] ]FIG] [25] [[キャッシュ指令]]は、その種類を識別する[[字句]]と、 [[引数]]とで構成されます。 [SRC[>>19]] [26] 種類を表す[[字句]]は、[[大文字・小文字不区別]]です [SRC[>>19]]。 [27] [[引数]]は省略できます。指定される場合は [CODE(HTTP)[[[=]]]] の後に[[字句]]または[[引用文字列]]を記述します。 [[受信者]]は、 [[RFC 7234]] で規定されている[[指令]]についてはどちらの構文も受け付ける[RUBYB[べき]@en[ought to]]で、 それ以外についてはどちらも受け付けなければ[['''なりません''']]。 [SRC[>>19]] ;; [28] なぜすべてについて [['''MUST''']] にしないのか謎です。 [FIG(railroad)[ = [[字句]] = ? == [CODE(HTTP)[[[=]]]] == | === [[字句]] === [[引用文字列]] ]FIG] ;; [31] [CODE(HTTP)[[[=]]]] の前後に [[BWS]] は認められていないようです。 [32] [[引数]]を指定するかどうかは、[[指令]]ごとに規定されています。 [[指令]]ごとに[[字句]]と[[引用文字列]]のどちらの構文が好ましいか規定されていることもあります。 ;; [33] [[RFC 7234]] で規定されている[[キャッシュ指令]]については、 明記されていない限り[[引数]]は定義されず、認められない [SRC[>>19]] とされています。 ;; [51] 新しい[[キャッシュ指令]]を規定する際には、[[引数]]が必須である場合に省略されると何を意味するかを規定することを検討するよう求められています [SRC[>>49]]。 しかし当の [[RFC 7234]] 自身はそのような規定を有していません。 * 文脈 [30] この[[ヘッダー]]は複数指定できます。 [17] [CODE(HTTP)[[[304]]]] の項も参照。 [60] [CODE(DOMi)@en[[[EventSource]]]] のための [[fetch]] では、 [[利用者エージェント]]は[[要求]]に [CODE(HTTP)@en[[[Cache-Control:]] [[no-cache]]]] を指定する[['''べきです''']] [SRC[>>59]]。 * 処理 [22] [[キャッシュ]]は、 [[RFC 7234]] の[[キャッシュ指令]]の要件に従わなければ[['''なりません''']] [SRC[>>19]]。 ;; [23] [[HTTP/1.0]] [[キャッシュ]]の中には、 [CODE(HTTP)@en[[[Cache-Control:]]]] を実装していないものもあります [SRC[>>19]]。 [24] [[串]]は、[[キャッシュ]]を有しているかどうかに関わらず、 [[キャッシュ指令]]をそのまま[[転送]]しなければ[['''なりません''']] [SRC[>>19]]。 [41] [[キャッシュ]]は、未知の[[キャッシュ指令]]を無視しなければ[['''なりません''']] [SRC[>>40]]。 [18] 同じ[[指令]]が複数ある場合について一般的な規定はありません。 一部の[[キャッシュ指令]]では規定があります ([[新鮮寿命]]を参照)。 ;; [50] 新たな[[キャッシュ指令]]を定義する時は複数回指定された時の意味を定義することを検討するよう求められています [SRC[>>49]] が、義務付けられているわけではなく、また [[RFC 7234]] 自身が規定する[[キャッシュ指令]]の多くでも定義はされていません。 [43] 各[[キャッシュ指令]]の処理モデルについては、それぞれの項を参照。 [42] なお、[[キャッシュ指令]]の中には [CODE(HTTP)@en[[[no-transform]]]] のように[[キャッシュ]]を持たない[[中間器]]にも適用されるものもあります。 また、[[AppCache]] や独自の[[キャッシュ]]システムなど [[HTTPキャッシュ]]以外の仕組みでも [CODE(HTTP)@en[[[Cache-Control:]]]] の一部の[[キャッシュ指令]]に従うものがあります。 ;; 各[[キャッシュ指令]]の項や[[キャッシュ可能性]]、[[キャッシュ項目]]を参照。 [61] [CODE(DOMi)@en[[[EventSource]]]] のための [[fetch]] では、 [[応答]]の[[キャッシュ]]の[[ヘッダー]]は無視する[['''べき''']]で、 [[キャッシュ]]を使う[['''べきではありません''']] [SRC[>>59]]。 * キャッシュ指令 [35] [CODE(HTTP)@en[[[Cache-Control:]]]] における個々の指定のことを、 [DFN[[RUBYB[[[キャッシュ指令]]]@en[cache directive]]]]といいます。 [36] [[要求]]における [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]の[[キャッシュ指令]]のことは[RUBYB[[[要求指令]]]@en[request directive]]、 [[応答]]における [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]の[[キャッシュ指令]]のことは[RUBYB[[[応答指令]]]@en[response directive]]と呼ばれています。 [FIG(list)[ ,*[CODE(ABNF)@en[[[cache-directive]]]],*[[要求]],*[[応答]],*出典 ,[CODE(HTTP)@en[[[access-restricted]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[auth-cache]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[cache-group]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[context]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[discard-context]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[x-gzip-ok]]]],,○ ,[CODE(HTTP)@en[[[im]]]],,○,[[RFC 3229]] ,[CODE(HTTP)@en[immutable]],,○ ,[CODE(HTTP)@en[[[inv-maxage]]]],,○,[[I-D]] ,[CODE(HTTP)@en[[[max-age]]]],○,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[max-stale]]]],○,,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[min-fresh]]]],○,,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[must-revalidate]]]],,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[no-cache]]]],○,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[no-store]]]],○,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[no-transform]]]],○,○,"[[RFC 2068]] ([[応答]]), [[RFC 2616]] ([[要求]]・[[応答]])" ,[CODE(HTTP)@en[[[only-if-cached]]]],○,,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[post-check]]]],,○ ,[CODE(HTTP)@en[[[pre-check]]]],,○ ,[CODE(HTTP)@en[[[private]]]],,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[proxy-public]]]],,○ ,[CODE(HTTP)@en[[[public]]]],,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[proxy-revalidate]]]],,○,"[[RFC 2068]], [[RFC 2616]]" ,[CODE(HTTP)@en[[[retain]]]],,○,[[RFC 3229]] ,[CODE(HTTP)@en[[[s-maxage]]]],,○,"[[RFC 2616]]" ,[CODE(HTTP)@en[[[stale-if-error]]]],,○,[[RFC 5861]] ,[CODE(HTTP)@en[[[stale-while-revalidate]]]],,○,[[RFC 5861]] ,[CODE(HTTP)@en[[[user-public]]]],,○ ,[CODE(HTTP)@en[[[x-wms-event-subscription]]]],,○ ,[CODE(HTTP)@en[[[x-wms-proxy-split]]]],,○ ,[CODE(HTTP)@en[[[x-wms-content-size]]]],,○ ,[CODE(HTTP)@en[[[x-wms-stream-type]]]],,○ ]FIG] [44] [[RFC 7234]] は「[CODE(HTTP)@en[community]]」という架空の[[キャッシュ指令]]の例を示しています [SRC[>>40]]。 [58] [[SSDP]] では [CODE(HTTP)@en[[[max-age]]]] のみ指定しなければなりません。 それ以外が指定されても無視しなければなりません。 [SRC[>>57]] [47] [[IANA登録簿]] (>>46) は [[RFC 7234]] で新設されました。 [48] しかし登録されていない[[キャッシュ指令]]の利用は特に禁止されていません。 [52] [[キャッシュ指令]]の一覧は >>53 の [[JSON]] ファイルにも含まれています。 [REFS[ - [53] [CITE@en[data-web-defs/headers.txt at master · manakai/data-web-defs]] ([TIME[2014-10-09 14:33:34 +09:00]] 版) ]REFS] * 歴史 [FIG(quote)[ [FIGCAPTION[ [4] RFC 2068・2616 (HTTP/1.1) 14.9 Cache-Control ]FIGCAPTION] > The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive [DEL[should]] [INS[is to]] be given in the response. Cache-control 一般頭欄は全てのキャッシュ機構が要求・応答の鎖に沿って 従わ'''なければならない'''指示を指定するのに使います。 指示はキャッシュが要求や応答の不利な妨害となるのを防ぐのを 目的として振舞いを指定します。これらの指示は典型的には既定の キャッシュ算法を上書きします。キャッシュ指示は一方向性のものであって、 要求に指示が使われていることは同じ指示が応答にも使われることを 暗示するものではありません。 > Note that HTTP/1.0 caches may not implement Cache-Control and [DEL[may]] [INS[might]] only implement Pragma: no-cache (see section 14.32). なお、 HTTP/1.0 キャッシュは Cache-Control を実装しておらず、 Pragma: no-cache だけを実装しているかもしれませぬ。 > Cache directives [DEL[must]] [INS[MUST]] be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives [DEL[may]] [INS[might]] be applicable to all recipients along the request/response chain. It is not possible to specify a cache- directive for a specific cache. キャッシュ指示は串や関門応用を通り抜けなければ'''なりません'''。 当該応用に対する意義の如何に関わらずです。なぜなら指示は 要求・応答の鎖にある全ての受信者に対して適用され得るからです。 特定キャッシュに対して cache-directive を指定することは不可能です。 > - Cache-Control = "Cache-Control" ":" 1#cache-directive - cache-directive = cache-request-directive | cache-response-directive > [DEL[ [PRE[ cache-request-directive = "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store" | "max-age" "=" delta-seconds | "max-stale" [ "=" delta-seconds ] | "min-fresh" "=" delta-seconds | "only-if-cached" | cache-extension ]PRE] ]DEL] > [INS[ [PRE[ cache-request-directive = "no-cache" ; Section 14.9.1 | "no-store" ; Section 14.9.2 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | "min-fresh" "=" delta-seconds ; Section 14.9.3 | "no-transform" ; Section 14.9.5 | "only-if-cached" ; Section 14.9.4 | cache-extension ; Section 14.9.6 ]PRE] ]INS] > [DEL[ [PRE[ cache-response-directive = "public" | "private" [ "=" <"> 1#field-name <"> ] | "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store" | "no-transform" | "must-revalidate" | "proxy-revalidate" | "max-age" "=" delta-seconds | cache-extension ]PRE] ]DEL] > [INS[ [PRE[ cache-response-directive = "public" ; Section 14.9.1 | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | "no-store" ; Section 14.9.2 | "no-transform" ; Section 14.9.5 | "must-revalidate" ; Section 14.9.4 | "proxy-revalidate" ; Section 14.9.4 | "max-age" "=" delta-seconds ; Section 14.9.3 | "s-maxage" "=" delta-seconds ; Section 14.9.3 | cache-extension ; Section 14.9.6 ]PRE] ]INS] > - cache-extension = token [ "=" ( token | quoted-string ) ] > When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol [DEL[may]] [INS[might]] apply these directives to header fields not defined in HTTP/1.1. 指示が 1#field-name パラメーターなしに現れる時、その指示は 要求又は応答全体に適用されます。その様な指示が 1#field-name パラメーターつきで現れる時、これはその名前の欄(達)にのみ 適用され、要求や応答の残りには適用されません。この機構は拡張性をもちます。 将来の版の HTTP プロトコルの実装はこれらの指示を HTTP/1.1 で定義されていない頭欄に適用するかもしれません。 > The cache-control directives can be broken down into these general categories: cache-control 指示は次の一般分類に分けることが出来ます。 > - [DEL[o]] [INS[-]] Restrictions on what is cach[INS[e]]able; these may only be imposed by the origin server. - [DEL[o]] [INS[-]] Restrictions on what may be stored by a cache; these may be imposed by either the origin server or the user agent. - [DEL[o]] [INS[-]] Modifications of the basic expiration mechanism; these may be imposed by either the origin server or the user agent. - [DEL[o]] [INS[-]] Controls over cache revalidation and reload; these may only be imposed by a user agent. - [DEL[o]] [INS[-]] Control over transformation of entities. - [DEL[o]] [INS[-]] Extensions to the caching system. - 何がキャッシュ可能かの制限。これは源サーバーのみ課せる。 - 何がキャッシュに蓄積可能かの制限。これは源サーバーと利用者代理者の 両者が課せる。 - 基本期限機構の編集。これは源サーバーと利用者代理者の 両者が課せる。 - キャッシュの再検証と再読み込みの制御。これは利用者代理者のみ課せる。 - 実体の転送に係る制御 - キャッシュ系統の拡張 * 14.9.1 What is Cach[INS[e]]able [INS[何がキャッシュ可能か]] > By default, a response is cach[INS[e]]able if the requirements of the request method, request header fields, and the response status indicate that it is cach[INS[e]]able. Section 13.4 summarizes these defaults for cach[INS[e]]ability. The following Cache-Control response directives allow an origin server to override the default cach[INS[e]]ability of a response: 既定では、応答はその要求 method, 要求頭欄及び応用状態がキャッシュ可能であると示していればキャッシュ可能です。 13.4節がキャッシュ可能性の既定をまとめています。 次の [CODE(HTTP)[Cache-Control]] 応答指示によって、 応答の既定のキャッシュ可能性を起源サーバーが上書きすることができます。 > :public: Indicates that the response [DEL[is cachable]] [INS[MAY be cached]] by any cache, even if it would normally be non-cach[INS[e]]able or cach[INS[e]]able only within a non-shared cache. (See also Authorization, section 14.8, for additional details.) その応答は、通常ならキャッシュ可能でないか又は非共有キャッシュ中でのみキャッシュ可能なキャッシュを含めてどんなキャッシュでもキャッシュして'''構いません'''。 (追加の詳細については14.8節の [CODE(HTTP)[[[Authorization]]]] をご覧下さい。) > :private: Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache [DEL[may]] [INS[MAY]] cache the response. 応答メッセージの全部又は一部が単独の利用者向けのものであって、 共有キャッシュはキャッシュしては'''ならない'''ことを示します。 これによって起源サーバーは、応答の特定の部分が唯一の利用者向けのものであって他の利用者による要求に対する妥当な応答ではないと表明できます。 私的 (非共有) キャッシュは応答をキャッシュしても'''構いません'''。 > Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content. 注意 : 単語 [CODE(HTTP)[private]] のこの用法は応答をキャッシュしても良いかを制御するだけであって、 メッセージ内容のプライバシーを保護することは出来ません。 > :no-cache:[DEL[Indicates that all or part of the response message MUST NOT be cached anywhere.]] [INS[If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.]] This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. ;[DEL[応答メッセージの全部又は一部がどこにおいてもキャッシュ'''してはならない'''ことを示します。]] [INS[[CODE(HTTP)[no-cache]] 指令が [CODE(ABNF)[field-name]] を指定していなければ、キャッシュは起源サーバーの再検証で成功を得なければ後続の要求を満足するためにこの応答を使っては'''なりません'''。]] この指令により、起源サーバーは、 クライアントの要求に対して腐った応答を返すように設定されているキャッシュでさえキャッシュすることを防ぐことができます。 [INS[ > If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. [CODE(HTTP)[no-cache]] 指令が1つ以上の [CODE(ABNF)[field-name]] を指定していれば、キャッシュは、キャッシュに関する他の制約の対象である 後続の要求を満足するのにこの応答を使っても'''構いません'''。 しかし、指定された [CODE(ABNF)[field-name]] は、起源サーバーによる再検証で成功を得ない限り後続の要求に対する応答では送っては'''なりません'''。 これによって、起源サーバーは、応答中の特定の頭欄が再利用されることを防ぎつつも、 応答の残りをキャッシュすることを認めることが出来ます。 ]INS] > Note: Most HTTP/1.0 caches will not recognize or obey this directive. 注意 : ほとんどの HTTP/1.0 キャッシュはこの指令を認識も従いもしません。 * 14.9.2 What May be Stored by Caches [INS[キャッシュは何を蓄積してもよいか]] ;; [CODE(HTTP)@en[[[no-store]]]] 参照。 * 14.9.3 Modifications of the Basic Expiration Mechanism [INS[基本満期機構の修正]] > The expiration time of an entity [DEL[may]] [INS[MAY]] be specified by the origin server using the Expires header (see section 14.21). Alternatively, it [DEL[may]] [INS[MAY]] be specified using the max-age directive in a response. [INS[When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, more restrictive cache directive is also present.]] > If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This [DEL[may]] [INS[might]] be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks. [INS[ > Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response does not include a Cache-Control header field, it SHOULD consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. > Note: An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network including older caches that do not understand that feature. The origin server will need to combine the new feature with an Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching the response. > :s-maxage: If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. The s- maxage directive is always ignored by a private cache. ]INS] > Note[DEL[:]] [INS[that]] most older caches, not compliant with this specification, do not implement any [DEL[Cache-Control]] [INS[cache-control]] directives. An origin server wishing to use a [DEL[Cache-Control]] [INS[cache-control]] directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache [DEL[may]] [INS[MAY]] exploit the requirement that the max-age directive overrides the Expires header, and the fact that pre-HTTP/1.1-compliant caches do not observe the max-age directive. > Other directives allow a[DEL[n]] user agent to modify the basic expiration mechanism. These directives [DEL[may]] [INS[MAY]] be specified on a request: > :max-age: Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless max-stale directive is also included, the client is not willing to accept a stale response. > :min-fresh: Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds. > :max-stale: Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age. > If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured to override the expiration time of a response, the cache MUST attach a Warning header to the stale response, using Warning [INS[1]]10 (Response is stale). [INS[ > A cache MAY be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive). > If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining the freshness of the cached entry for that request. ]INS] * 14.9.4 Cache Revalidation and Reload Controls [INS[キャッシュ再検証及び再読み込み制御]] > Sometimes a[DEL[n]] user agent [DEL[may]] [INS[might]] want or need to insist that a cache revalidate its cache entry with the origin server (and not just with the next cache along the path to the origin server), or to reload its cache entry from the origin server. End-to-end revalidation [DEL[may]] [INS[might]] be necessary if either the cache or the origin server has overestimated the expiration time of the cached response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason. > End-to-end revalidation may be requested either when the client does not have its own local cached copy, in which case we call it "unspecified end-to-end revalidation", or when the client does have a local cached copy, in which case we call it "specific end-to-end revalidation." > The client can specify these three kinds of action using Cache-Control request directives: > :End-to-end reload: The request includes a "no-cache" [DEL[Cache-Control]] [INS[cache-control]] directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". [DEL[No field]] [INS[Field]] names [DEL[may]] [INS[MUST NOT]] be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request. > :Specific end-to-end revalidation: The request includes a "max-age=0" [DEL[Cache-Control]] [INS[cache-control] directive, which]] forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional with the client's current validator. > :Unspecified end-to-end revalidation: The request includes "max-age=0" [DEL[Cache-Control]] [INS[cache-control] directive, which]] forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional; the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional with its current validator. > :[INS[max-age]]: When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator [DEL[may]] [INS[might]] differ from the validator currently stored with the cache entry. In this case, the cache [DEL[may]] [INS[might]] use either validator in making its own request without affecting semantic transparency. However, the choice of validator may affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache should return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache [DEL[should]] [INS[can]] compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response. If a request includes the no-cache directive, it [DEL[should not]] [INS[SHOULD NOT]] include min-fresh, max-stale, or max-age. > :[INS[only-if-cached]]: In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the only-if-cached directive in a request. If it receives this directive, a cache SHOULD either respond using a cached entry that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request MAY be forwarded within that group of caches. > :[INS[must-revalidate]]: Because a cache [DEL[may]] [INS[MAY]] be configured to ignore a server's specified expiration time, and because a client request [DEL[may]] [INS[MAY]] include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache [DEL[must]] [INS[MUST]] do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.) > The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response. > Servers [DEL[should]] [INS[SHOULD]] send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails. > Although this is not recommended, user agents operating under severe connectivity constraints [DEL[may]] [INS[MAY]] violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided. The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation. > :[INS[proxy-revalidate]]: The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later return the response without needing to revalidate it (since it has already been authenticated once by that user), while still requiring proxies that service many users to revalidate each time (in order to make sure that each user has been authenticated). Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at all. * 14.9.5 No-Transform Directive [INS[非変換指令]] ;; [CODE(HTTP)@en[[[no-transform]]]] 参照。 * 14.9.6 Cache Control Extensions [INS[キャッシュ制御拡張]] > The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional assigned value. Informational extensions (those which do not require a change in cache behavior) [DEL[may]] [INS[MAY]] be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications which do not understand the new directive will default to the behavior specified by the standard directive, and those that understand the new directive will recognize it as modifying the requirements associated with the standard directive. In this way, extensions to the [DEL[Cache-Control]] [INS[cache-control]] directives can be made without requiring changes to the base protocol. > This extension mechanism depends on a[INS[n]] HTTP cache obeying all of the cache-control directives defined for its native HTTP-version, obeying certain extensions, and ignoring all directives that it does not understand. > For example, consider a hypothetical new response directive called [DEL["]]community[DEL["]] which acts as a modifier to the [DEL["]]private[DEL["]] directive. We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members of the community named within its value may cache the response. An origin server wishing to allow the [DEL["]]UCI[DEL["]] community to use an otherwise private response in their shared cache(s) [DEL[may]] [INS[could]] do so by including > - [SAMP(HTTP)[Cache-Control: private, community="UCI"]] > A cache seeing this header field will act correctly even if the cache does not understand the [DEL["]]community[DEL["]] cache-extension, since it will also see and understand the [DEL["]]private[DEL["]] directive and thus default to the safe behavior. > Unrecognized cache-directives MUST be ignored; it is assumed that any cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard directives (or the response's default cach[INS[e]]ability) such that the cache behavior will remain minimally correct even if the cache does not understand the extension(s). ]FIG] [REFS[ - [4] [CITE@en[RFC 3143 - Known HTTP Proxy/Caching Problems]] ([TIME[2008-08-30 12:43:01 +09:00]] 版) ]REFS] [9] [CITE@en[Guidelines for Web Content Transformation Proxies 1.0]] ( ([TIME[2010-10-22 17:20:31 +09:00]] 版)) [10] [CITE[#208 (IANA registry for cache-control directives) – httpbis]] ( ([TIME[2012-03-06 13:46:28 +09:00]] 版)) [11] [CITE[#317 (Cache-Control directive case sensitivity) – httpbis]] ( ([TIME[2012-03-06 13:47:33 +09:00]] 版)) [12] [CITE@en[draft-mogul-http-revalidate-01 - Forcing HTTP/1.1 proxies to revalidate responses]] ( ([TIME[2012-01-28 14:19:45 +09:00]] 版)) [13] [CITE@en[RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks]] ( ([TIME[2011-12-04 10:31:11 +09:00]] 版)) [14] [CITE@en[RFC 2326 - Real Time Streaming Protocol (RTSP)]] ( ([TIME[2012-02-26 01:15:33 +09:00]] 版)) [15] [CITE@en[RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2)]] ( ([TIME[2012-11-13 15:18:40 +09:00]] 版)) [16] [CITE@en[RFC 3507 - Internet Content Adaptation Protocol (ICAP)]] ( ([TIME[2014-06-08 07:17:07 +09:00]] 版)) ** RFC 5861 [55] [DFN[[[RFC 5861]]]] は追加の[[キャッシュ指令]]を2つ規定しています。 [FIG(short list)[ - [CODE(HTTP)@en[[[stale-if-error]]]] - [CODE(HTTP)@en[[[stale-while-revalidate]]]] ]FIG] [REFS[ - [54] [CITE@en[RFC 5861 - HTTP Cache-Control Extensions for Stale Content]] ([TIME[2014-09-10 12:23:24 +09:00]] 版) - [56] [CITE[RFC Errata Report]] ([TIME[2014-11-15 15:29:44 +09:00]] 版) ]REFS] * 実装 [1] [[Google]] からの応答に [CODE(HTTP)[x-gzip-ok=""]] ってのがついてました。 - [2] ''Q234067 - HOWTO: Prevent Caching in Internet Explorer'' : [[M$]] も [CODE(HTTP)[[[Pragma]]]] より [CODE(HTTP)[Cache-Control]] を推奨していました。ところで、この文書によると、 [CODE(HTTP)[Cache-Control: no-cache]] には対応しているけど [CODE(HTML)[<[CODE(HTMLe)[[[meta]]]] [CODE(HTMLa)[[[http-equiv]]]]="cache-control" [CODE(HTMLa)[[[content]]]]="no-cache">]] には対応していないとか。妥当な態度ですね。 [7] [[IE7]] の [[XHR]] で [CODE(JS)@en[xhr.[[setRequestHeader]] ('[[Cache-Control]]', '[[no-cache]]')]] したら何か変なエラーが出た。。。 [[IE7]] が勝手にキャッシュするから困ってるのにどうすりゃいいのよwwwwww (結局 [[query]] にランダム値つけて対処したw) [305] [CITE@ja-JP[''''''[''''''HOWTO'''''']'''''' Internet Explorer でキャッシュを無効にする]] ( ([TIME[2014-09-23 13:01:27 +09:00]] 版)) [REFS[ - [38] [CITE[Hatena::MobileGateway]] ([TIME[2014-10-05 12:27:54 +09:00]] 版) ]REFS] [39] >>38 は [CODE(HTML)@en[<[[meta]] [[http-equiv]]=[[Cache-Control]]>]] を実装しているようです。 * 統計 [5] [CITE@en[HTTP/1.1 Cache-Control header]] ([TIME[2009-07-19 11:21:36 +09:00]] 版) * 例 [3] [CODE(HTTP example code)@en[Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0]] [SRC@en[[[XOOPS]]]] ([[名無しさん]] [sage] [WEAK[2005-08-18 10:50:21 +00:00]]) [6] >>5 より > - Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0 - Cache-Control: post-check=0, pre-check=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 - Cache-Control: , - Cache-Control: 7200 - Cache-Control: "no-cache" - Cache-Control: False - Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private - Cache-Control: post-check=-1, pre-check=-1 * 関連 [8] 次の[[ヘッダー]]にはキャッシュ制御に関する規定があります。 [FIG(short list)[ - [CODE(HTTP)@en[[[Authorization:]]]] - [CODE(HTTP)@en[[[Set-Cookie:]]]] - [CODE(HTTP)@en[[[Set-Cookie2:]]]] ]FIG] [62] [CITE@en[EventSource has no need to set Cache-Control · whatwg/html@6f47a53]] ([TIME[2016-03-08 18:38:37 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [63] [CITE@ja[CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog]] ( ([TIME[2017-06-23 11:54:35 +09:00]])) ]FIGCAPTION] > 切り替え前のCDNプロバイダはCache-Controlヘッダではなく、CDNの設定でキャッシュを制御することで、メルカリWeb版においては全くキャッシュが行われないようにしていました。 > 切り替え後のCDNプロバイダでは、Cache-Controlヘッダでキャッシュの制御が可能であるため(この制御はnginxの設定により行います)、CDNの設定によるキャッシュ無効化は行わず切り替えを行いました。切替前の検証では手元のマシンのhostsファイルを編集し、数回アクセスを行い問題なく動作していることを確認しました。 > 問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは > Cache-Control: private > が含まれている場合のみとわかりました。Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました。このためCDNのサーバ上にお客さまの情報が含まれたキャッシュが作成され、別のお客さまへ配信される事態に至りました。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [64] [CITE@ja[キャッシュの詳細  |  Cloud CDN のドキュメント  |  Google Cloud Platform]] ( ([TIME[2016-11-03 02:59:38 +09:00]])) ]FIGCAPTION] > 次の条件をすべて満たしている場合にのみ、Cloud CDN キャッシュにレスポンスが保存されます。 > キャッシュが有効になっているバックエンド サービスから提供されている。 > GET リクエストに対するレスポンスである。 > ステータス コードが 200、203、300、301、302、307 または 410 である。 > Cache-Control: public ディレクティブが設定されている。 > Cache-Control: s-maxage、Cache-Control: max-age または Expires ヘッダーがある。 > Content-Length ヘッダーまたは Transfer-Encoding ヘッダーがある。 > サービス自身が生成した Date ヘッダーがある。HTTP(S) ロードバランサを経由せずに、VM インスタンスに直接リクエストを送信すると、このヘッダーの有無を確認できます。ロードバランサが独自の Date ヘッダーを追加する場合がありますが、このヘッダーだけではキャッシュの条件を満たしません。 > レスポンスがキャッシュに保存されるかどうか確認する方法があります。次の条件を満たす場合、レスポンスはキャッシュに保存されません。 > Set-Cookie ヘッダーがある。 > 本体が 4 MB を超えている。 > Vary ヘッダーに Accept、Accept-Encoding、Origin 以外の値が設定されている。 > Cache-Control: no-store、no-cache または private ディレクティブが設定されている。 > 対応するリクエストに Cache-Control: no-store ディレクティブが設定されている。 > Cloud CDN でキャッシュに保存するレスポンスを増やすため、これらの要件は今後緩和される可能性があります。レスポンスがキャッシュに保存されないようにするには、次の操作を行います。どのキャッシュにもレスポンスを保存しない場合には(ウェブブラウザのキャッシュを含む)、Cache-Control: no-store ヘッダーを追加します。Cloud CDN のキャッシュに保存しない場合には、Cache-Control: private ヘッダーを追加します。 ]FIG] [65] [CITE@ja[HTTP キャッシュ  |  Web  |  Google Developers]] ([TIME[2017-05-19 08:04:32 +09:00]]) [66] [CITE[Cache-Control in the wild]] ([TIME[2020-07-07 00:02:36 +09:00]]) [67] [CITE@en-us['''['''MS-WMSP''']''': Cache-Control | Microsoft Docs]] ([[openspecs-office]]著, [TIME[2020-07-07 11:26:44 +09:00]]) [68] [CITE@ja-JP[コンテンツがキャッシュに保持される期間 (有効期限) の管理 - Amazon CloudFront]] ([TIME[2023-02-16T02:21:00.000Z]], [TIME[2023-02-16T05:56:06.910Z]])