5.2.2. Response Cache-Control Directives (响应缓存控制指令)
🇬🇧 English
This section defines cache directives that can be used by an origin server or intermediary in an HTTP response.
5.2.2.1. must-revalidate
The "must-revalidate" response directive indicates that once the response has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
The must-revalidate directive ought to be used by servers if and only if failure to validate a request could result in incorrect operation, such as a silently unexecuted financial transaction.
5.2.2.2. no-cache
Argument: #field-name (optional)
The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using the response to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
If the no-cache response directive specifies 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, any field-names specified 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.
Note: Most HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often handled by implementations as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented.
5.2.2.3. no-store
The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
5.2.2.4. no-transform
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
5.2.2.5. public
The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache. (See also Section 3.2, which discusses the effect of the Authorization header field on cacheability.)
5.2.2.6. private
Argument: #field-name (optional)
The "private" response directive indicates that the response is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.
If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated with the listed response header fields. That is, a shared cache MUST NOT store the specified field-names, whereas it MAY store the remainder of the response message.
Note: This directive is not a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
5.2.2.7. proxy-revalidate
The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.
5.2.2.8. max-age
Argument: delta-seconds
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the quoted-string form.
5.2.2.9. s-maxage
Argument: delta-seconds
The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the quoted-string form.
🇨🇳 中文
本节定义源服务器或中间层可以在HTTP响应中使用的缓存指令。
5.2.2.1. must-revalidate
"must-revalidate"响应指令表示，一旦响应变得过期，缓存不得 (MUST NOT) 在未经源服务器成功验证的情况下使用该响应来满足后续请求。
must-revalidate指令对于支持某些协议功能的可靠操作是必要的。在所有情况下，缓存必须 (MUST) 遵守must-revalidate指令; 特别是，如果缓存因任何原因无法到达源服务器，则它必须 (MUST) 生成504（网关超时）响应。
服务器应该 (ought to) 使用must-revalidate指令，当且仅当验证请求失败可能导致不正确的操作时，例如静默未执行的金融交易。
5.2.2.2. no-cache
参数: #field-name (可选)
"no-cache"响应指令表示，在未经源服务器成功验证的情况下，不得 (MUST NOT) 使用该响应来满足后续请求。这允许源服务器防止缓存在不联系它的情况下使用响应来满足请求，即使是已配置为发送过期响应的缓存也是如此。
如果no-cache响应指令指定了一个或多个字段名，则缓存可以 (MAY) 使用响应来满足后续请求，但需遵守缓存的任何其他限制。但是，在未经源服务器成功重新验证的情况下，不得 (MUST NOT) 在对后续请求的响应中发送指定的任何字段名。这允许源服务器防止在响应中重新使用某些头字段，同时仍允许缓存响应的其余部分。
注意: 大多数HTTP/1.0缓存将不识别或不遵守此指令。此外，带有字段名的no-cache响应指令通常被实现处理为好像接收到无限定的no-cache指令一样; 也就是说，对限定形式的特殊处理并未被广泛实现。
5.2.2.3. no-store
"no-store"响应指令表示缓存不得 (MUST NOT) 存储直接请求或响应的任何部分。此指令适用于私有缓存和共享缓存。在此上下文中，"不得存储"意味着缓存不得 (MUST NOT) 有意将信息存储在非易失性存储中，并且必须 (MUST) 在转发后尽快尽力从易失性存储中删除信息。
此指令不是确保隐私的可靠或充分机制。特别是，恶意或受损的缓存可能不识别或不遵守此指令，并且通信网络可能容易受到窃听。
5.2.2.4. no-transform
"no-transform"响应指令表示中间层（无论是否实现缓存）不得 (MUST NOT) 转换有效载荷，如 [RFC7230] 的第5.7.2节所定义。
5.2.2.5. public
"public"响应指令表示任何缓存都可以 (MAY) 存储响应，即使响应通常是不可缓存的或仅在私有缓存中可缓存。（另请参见第3.2节，其中讨论了Authorization头字段对可缓存性的影响。）
5.2.2.6. private
参数: #field-name (可选)
"private"响应指令表示响应旨在供单个用户使用，并且不得 (MUST NOT) 由共享缓存存储。私有缓存可以 (MAY) 存储响应并将其重用于以后的请求，即使响应通常是不可缓存的。
如果private响应指令指定了一个或多个字段名，则此要求仅限于与列出的响应头字段相关联的字段值。也就是说，共享缓存不得 (MUST NOT) 存储指定的字段名，而它可以 (MAY) 存储响应消息的其余部分。
注意: 此指令不是确保隐私的可靠或充分机制。特别是，恶意或受损的缓存可能不识别或不遵守此指令，并且通信网络可能容易受到窃听。
5.2.2.7. proxy-revalidate
"proxy-revalidate"响应指令与must-revalidate响应指令具有相同的含义，除了它不适用于私有缓存。
5.2.2.8. max-age
参数: delta-seconds
"max-age"响应指令表示，当响应的年龄大于指定的秒数后，应将其视为过期。
此指令使用参数语法的令牌形式: 例如，'max-age=5'而不是'max-age="5"'。发送方不应该 (SHOULD NOT) 生成引号字符串形式。
5.2.2.9. s-maxage
参数: delta-seconds
"s-maxage"响应指令表示，在共享缓存中，此指令指定的最大年龄将覆盖max-age指令或Expires头字段指定的最大年龄。s-maxage指令还隐含proxy-revalidate响应指令的语义。
此指令使用参数语法的令牌形式: 例如，'s-maxage=10'而不是's-maxage="10"'。发送方不应该 (SHOULD NOT) 生成引号字符串形式。
🇯🇵 日本語
このセクションでは、オリジンサーバーまたは中間層がHTTPレスポンスで使用できるキャッシュディレクティブを定義する。
5.2.2.1. must-revalidate
"must-revalidate"レスポンスディレクティブは、レスポンスが古くなった後、キャッシュがオリジンサーバーでの正常な検証なしにそのレスポンスを使用して後続のリクエストを満たしてはならない (MUST NOT) ことを示す。
must-revalidateディレクティブは、特定のプロトコル機能の信頼できる動作をサポートするために必要である。すべての状況において、キャッシュはmust-revalidateディレクティブに従わなければならない (MUST); 特に、キャッシュが何らかの理由でオリジンサーバーに到達できない場合、504（Gateway Timeout）レスポンスを生成しなければならない (MUST)。
must-revalidateディレクティブは、リクエストの検証に失敗すると、黙って実行されない金融取引など、誤った操作につながる可能性がある場合に限り、サーバーによって使用されるべきである (ought to)。
5.2.2.2. no-cache
引数: #field-name (オプション)
"no-cache"レスポンスディレクティブは、オリジンサーバーでの正常な検証なしに、そのレスポンスを後続のリクエストを満たすために使用してはならない (MUST NOT) ことを示す。これにより、オリジンサーバーは、古いレスポンスを送信するように構成されているキャッシュであっても、それに接触せずにレスポンスを使用してリクエストを満たすことを防ぐことができる。
no-cacheレスポンスディレクティブが1つ以上のフィールド名を指定する場合、キャッシュはキャッシングに関する他の制限に従って、後続のリクエストを満たすためにレスポンスを使用してもよい (MAY)。ただし、オリジンサーバーで正常に再検証されない限り、指定されたフィールド名を後続のリクエストへのレスポンスで送信してはならない (MUST NOT)。これにより、オリジンサーバーは、レスポンスの残りの部分のキャッシングを許可しながら、レスポンス内の特定のヘッダーフィールドの再使用を防ぐことができる。
注: ほとんどのHTTP/1.0キャッシュは、このディレクティブを認識または遵守しない。また、フィールド名を持つno-cacheレスポンスディレクティブは、多くの場合、無条件のno-cacheディレクティブを受信したかのように実装によって処理される; つまり、条件付き形式の特別な処理は広く実装されていない。
5.2.2.3. no-store
"no-store"レスポンスディレクティブは、キャッシュが直接のリクエストまたはレスポンスのいずれの部分も保存してはならない (MUST NOT) ことを示す。このディレクティブはプライベートキャッシュと共有キャッシュの両方に適用される。このコンテキストでの「保存してはならない」とは、キャッシュが意図的に不揮発性ストレージに情報を保存してはならず (MUST NOT)、転送後できるだけ速やかに揮発性ストレージから情報を削除するために最善の努力をしなければならない (MUST) ことを意味する。
このディレクティブは、プライバシーを確保するための信頼できるまたは十分なメカニズムではない。特に、悪意のあるまたは侵害されたキャッシュはこのディレクティブを認識または遵守しない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性がある。
5.2.2.4. no-transform
"no-transform"レスポンスディレクティブは、中間層（キャッシュを実装しているかどうかに関係なく）が、[RFC7230] のセクション5.7.2で定義されているように、ペイロードを変換してはならない (MUST NOT) ことを示す。
5.2.2.5. public
"public"レスポンスディレクティブは、通常はキャッシュ不可能であるか、プライベートキャッシュ内でのみキャッシュ可能なレスポンスであっても、任意のキャッシュがレスポンスを保存してもよい (MAY) ことを示す。（キャッシュ可能性に対するAuthorizationヘッダーフィールドの影響について議論しているセクション3.2も参照。）
5.2.2.6. private
引数: #field-name (オプション)
"private"レスポンスディレクティブは、レスポンスが単一のユーザー向けであり、共有キャッシュによって保存されてはならない (MUST NOT) ことを示す。プライベートキャッシュは、通常はキャッシュ不可能なレスポンスであっても、レスポンスを保存し、後のリクエストのためにそれを再利用してもよい (MAY)。
privateレスポンスディレクティブが1つ以上のフィールド名を指定する場合、この要件はリストされたレスポンスヘッダーフィールドに関連付けられたフィールド値に限定される。つまり、共有キャッシュは指定されたフィールド名を保存してはならず (MUST NOT)、レスポンスメッセージの残りの部分を保存してもよい (MAY)。
注: このディレクティブは、プライバシーを確保するための信頼できるまたは十分なメカニズムではない。特に、悪意のあるまたは侵害されたキャッシュはこのディレクティブを認識または遵守しない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性がある。
5.2.2.7. proxy-revalidate
"proxy-revalidate"レスポンスディレクティブは、プライベートキャッシュには適用されないことを除いて、must-revalidateレスポンスディレクティブと同じ意味を持つ。
5.2.2.8. max-age
引数: delta-seconds
"max-age"レスポンスディレクティブは、レスポンスの経過時間が指定された秒数より大きい場合、それを古いものと見なすべきであることを示す。
このディレクティブは引数構文のトークン形式を使用する: 例えば、'max-age=5'であり'max-age="5"'ではない。送信者は引用符で囲まれた文字列形式を生成すべきではない (SHOULD NOT)。
5.2.2.9. s-maxage
引数: delta-seconds
"s-maxage"レスポンスディレクティブは、共有キャッシュにおいて、このディレクティブで指定された最大経過時間がmax-ageディレクティブまたはExpiresヘッダーフィールドで指定された最大経過時間を上書きすることを示す。s-maxageディレクティブは、proxy-revalidateレスポンスディレクティブのセマンティクスも暗示する。
このディレクティブは引数構文のトークン形式を使用する: 例えば、's-maxage=10'であり's-maxage="10"'ではない。送信者は引用符で囲まれた文字列形式を生成すべきではない (SHOULD NOT)。
🇫🇷 Français
Cette section définit les directives de cache qui peuvent être utilisées par un serveur d'origine ou un intermédiaire dans une réponse HTTP.
5.2.2.1. must-revalidate
La directive de réponse "must-revalidate" indique qu'une fois que la réponse est devenue périmée, un cache NE DOIT PAS (MUST NOT) utiliser la réponse pour satisfaire des requêtes ultérieures sans validation réussie sur le serveur d'origine.
La directive must-revalidate est nécessaire pour prendre en charge le fonctionnement fiable de certaines fonctionnalités du protocole. Dans toutes les circonstances, un cache DOIT (MUST) obéir à la directive must-revalidate ; en particulier, si un cache ne peut atteindre le serveur d'origine pour quelque raison que ce soit, il DOIT (MUST) générer une réponse 504 (Gateway Timeout).
La directive must-revalidate devrait (ought to) être utilisée par les serveurs si et seulement si l'échec de validation d'une requête pourrait entraîner un fonctionnement incorrect, tel qu'une transaction financière silencieusement non exécutée.
5.2.2.2. no-cache
Argument : #field-name (optionnel)
La directive de réponse "no-cache" indique que la réponse NE DOIT PAS (MUST NOT) être utilisée pour satisfaire une requête ultérieure sans validation réussie sur le serveur d'origine. Cela permet à un serveur d'origine d'empêcher un cache d'utiliser la réponse pour satisfaire une requête sans le contacter, même par des caches qui ont été configurés pour envoyer des réponses périmées.
Si la directive de réponse no-cache spécifie un ou plusieurs noms de champs, alors un cache PEUT (MAY) utiliser la réponse pour satisfaire une requête ultérieure, sous réserve de toute autre restriction sur la mise en cache. Cependant, tous les noms de champs spécifiés NE DOIVENT PAS (MUST NOT) être envoyés dans la réponse à une requête ultérieure sans revalidation réussie avec le serveur d'origine. Cela permet à un serveur d'origine d'empêcher la réutilisation de certains champs d'en-tête dans une réponse, tout en permettant la mise en cache du reste de la réponse.
Remarque : La plupart des caches HTTP/1.0 ne reconnaîtront pas ou n'obéiront pas à cette directive. De plus, les directives de réponse no-cache avec des noms de champs sont souvent traitées par les implémentations comme si une directive no-cache non qualifiée avait été reçue ; c'est-à-dire que le traitement spécial pour la forme qualifiée n'est pas largement implémenté.
5.2.2.3. no-store
La directive de réponse "no-store" indique qu'un cache NE DOIT PAS (MUST NOT) stocker une partie quelconque de la requête immédiate ou de la réponse. Cette directive s'applique aux caches privés et partagés. "NE DOIT PAS stocker" dans ce contexte signifie que le cache NE DOIT PAS (MUST NOT) intentionnellement stocker les informations dans un stockage non volatile, et DOIT (MUST) faire un effort maximal pour supprimer les informations du stockage volatile aussi rapidement que possible après les avoir transmises.
Cette directive N'EST PAS un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines.
5.2.2.4. no-transform
La directive de réponse "no-transform" indique qu'un intermédiaire (qu'il implémente ou non un cache) NE DOIT PAS (MUST NOT) transformer la charge utile, comme défini dans la Section 5.7.2 de [RFC7230].
5.2.2.5. public
La directive de réponse "public" indique que tout cache PEUT (MAY) stocker la réponse, même si la réponse serait normalement non cacheable ou cacheable uniquement dans un cache privé. (Voir également la Section 3.2, qui discute de l'effet du champ d'en-tête Authorization sur la cacheabilité.)
5.2.2.6. private
Argument : #field-name (optionnel)
La directive de réponse "private" indique que la réponse est destinée à un seul utilisateur et NE DOIT PAS (MUST NOT) être stockée par un cache partagé. Un cache privé PEUT (MAY) stocker la réponse et la réutiliser pour des requêtes ultérieures, même si la réponse serait normalement non cacheable.
Si la directive de réponse private spécifie un ou plusieurs noms de champs, cette exigence est limitée aux valeurs de champs associées aux champs d'en-tête de réponse listés. C'est-à-dire qu'un cache partagé NE DOIT PAS (MUST NOT) stocker les noms de champs spécifiés, alors qu'il PEUT (MAY) stocker le reste du message de réponse.
Remarque : Cette directive n'est pas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines.
5.2.2.7. proxy-revalidate
La directive de réponse "proxy-revalidate" a la même signification que la directive de réponse must-revalidate, sauf qu'elle ne s'applique pas aux caches privés.
5.2.2.8. max-age
Argument : delta-seconds
La directive de réponse "max-age" indique que la réponse doit être considérée comme périmée après que son âge soit supérieur au nombre de secondes spécifié.
Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 'max-age=5' et non 'max-age="5"'. Un émetteur NE DEVRAIT PAS (SHOULD NOT) générer la forme de chaîne entre guillemets.
5.2.2.9. s-maxage
Argument : delta-seconds
La directive de réponse "s-maxage" indique que, dans les caches partagés, l'âge maximum spécifié par cette directive remplace l'âge maximum spécifié soit par la directive max-age soit par le champ d'en-tête Expires. La directive s-maxage implique également la sémantique de la directive de réponse proxy-revalidate.
Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 's-maxage=10' et non 's-maxage="10"'. Un émetteur NE DEVRAIT PAS (SHOULD NOT) générer la forme de chaîne entre guillemets.
🇩🇪 Deutsch
Dieser Abschnitt definiert Cache-Direktiven, die ein Ursprungsserver oder Vermittler in einer HTTP-Antwort verwenden kann.
5.2.2.1. must-revalidate
Die "must-revalidate"-Antwortdirektive gibt an, dass ein Cache, sobald die Antwort veraltet ist, die Antwort NICHT (MUST NOT) verwenden darf, um nachfolgende Anfragen ohne erfolgreiche Validierung auf dem Ursprungsserver zu erfüllen.
Die must-revalidate-Direktive ist notwendig, um den zuverlässigen Betrieb für bestimmte Protokollfunktionen zu unterstützen. Unter allen Umständen MUSS (MUST) ein Cache der must-revalidate-Direktive gehorchen; insbesondere, wenn ein Cache aus irgendeinem Grund den Ursprungsserver nicht erreichen kann, MUSS (MUST) er eine 504 (Gateway Timeout)-Antwort generieren.
Die must-revalidate-Direktive sollte (ought to) von Servern verwendet werden, wenn und nur wenn das Versagen der Validierung einer Anfrage zu einem inkorrekten Betrieb führen könnte, wie z. B. eine stillschweigend nicht ausgeführte Finanztransaktion.
5.2.2.2. no-cache
Argument: #field-name (optional)
Die "no-cache"-Antwortdirektive gibt an, dass die Antwort NICHT (MUST NOT) verwendet werden darf, um eine nachfolgende Anfrage ohne erfolgreiche Validierung auf dem Ursprungsserver zu erfüllen. Dies ermöglicht es einem Ursprungsserver, zu verhindern, dass ein Cache die Antwort verwendet, um eine Anfrage zu erfüllen, ohne ihn zu kontaktieren, selbst durch Caches, die so konfiguriert wurden, dass sie veraltete Antworten senden.
Wenn die no-cache-Antwortdirektive einen oder mehrere Feldnamen angibt, dann DARF (MAY) ein Cache die Antwort verwenden, um eine nachfolgende Anfrage zu erfüllen, vorbehaltlich anderer Einschränkungen beim Caching. Jedoch DÜRFEN (MUST NOT) alle angegebenen Feldnamen NICHT in der Antwort auf eine nachfolgende Anfrage gesendet werden, ohne erfolgreiche Revalidierung mit dem Ursprungsserver. Dies ermöglicht es einem Ursprungsserver, die Wiederverwendung bestimmter Header-Felder in einer Antwort zu verhindern, während das Caching des Rests der Antwort weiterhin erlaubt wird.
Hinweis: Die meisten HTTP/1.0-Caches werden diese Direktive nicht erkennen oder befolgen. Außerdem werden no-cache-Antwortdirektiven mit Feldnamen von Implementierungen oft so behandelt, als ob eine uneingeschränkte no-cache-Direktive empfangen wurde; d. h., die spezielle Behandlung für die qualifizierte Form ist nicht weit verbreitet implementiert.
5.2.2.3. no-store
Die "no-store"-Antwortdirektive gibt an, dass ein Cache KEINEN Teil (MUST NOT) der unmittelbaren Anfrage oder Antwort speichern darf. Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. "DARF NICHT speichern" bedeutet in diesem Kontext, dass der Cache die Informationen NICHT absichtlich (MUST NOT) in nicht flüchtigem Speicher speichern darf und sich nach bestem Bemühen (MUST) darum bemühen muss, die Informationen so schnell wie möglich nach der Weiterleitung aus dem flüchtigen Speicher zu entfernen.
Diese Direktive ist KEIN zuverlässiger oder ausreichender Mechanismus zur Gewährleistung der Privatsphäre. Insbesondere können bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.
5.2.2.4. no-transform
Die "no-transform"-Antwortdirektive gibt an, dass ein Vermittler (unabhängig davon, ob er einen Cache implementiert oder nicht) die Payload NICHT transformieren DARF (MUST NOT), wie in Abschnitt 5.7.2 von [RFC7230] definiert.
5.2.2.5. public
Die "public"-Antwortdirektive gibt an, dass jeder Cache die Antwort speichern DARF (MAY), selbst wenn die Antwort normalerweise nicht cachefähig oder nur innerhalb eines privaten Caches cachefähig wäre. (Siehe auch Abschnitt 3.2, der die Auswirkung des Authorization-Header-Felds auf die Cachefähigkeit diskutiert.)
5.2.2.6. private
Argument: #field-name (optional)
Die "private"-Antwortdirektive gibt an, dass die Antwort für einen einzelnen Benutzer bestimmt ist und NICHT (MUST NOT) von einem gemeinsam genutzten Cache gespeichert werden darf. Ein privater Cache DARF (MAY) die Antwort speichern und für spätere Anfragen wiederverwenden, selbst wenn die Antwort normalerweise nicht cachefähig wäre.
Wenn die private-Antwortdirektive einen oder mehrere Feldnamen angibt, ist diese Anforderung auf die Feldwerte beschränkt, die mit den aufgelisteten Antwort-Header-Feldern verbunden sind. Das heißt, ein gemeinsam genutzter Cache DARF NICHT (MUST NOT) die angegebenen Feldnamen speichern, während er den Rest der Antwortnachricht speichern DARF (MAY).
Hinweis: Diese Direktive ist kein zuverlässiger oder ausreichender Mechanismus zur Gewährleistung der Privatsphäre. Insbesondere können bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.
5.2.2.7. proxy-revalidate
Die "proxy-revalidate"-Antwortdirektive hat dieselbe Bedeutung wie die must-revalidate-Antwortdirektive, außer dass sie nicht für private Caches gilt.
5.2.2.8. max-age
Argument: delta-seconds
Die "max-age"-Antwortdirektive gibt an, dass die Antwort als veraltet betrachtet werden soll, nachdem ihr Alter größer ist als die angegebene Anzahl von Sekunden.
Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'max-age=5' nicht 'max-age="5"'. Ein Absender SOLLTE NICHT (SHOULD NOT) die Form mit Anführungszeichen generieren.
5.2.2.9. s-maxage
Argument: delta-seconds
Die "s-maxage"-Antwortdirektive gibt an, dass in gemeinsam genutzten Caches das durch diese Direktive angegebene maximale Alter das durch die max-age-Direktive oder das Expires-Header-Feld angegebene maximale Alter überschreibt. Die s-maxage-Direktive impliziert auch die Semantik der proxy-revalidate-Antwortdirektive.
Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 's-maxage=10' nicht 's-maxage="10"'. Ein Absender SOLLTE NICHT (SHOULD NOT) die Form mit Anführungszeichen generieren.
🇮🇹 Italiano
Questa sezione definisce le direttive di cache che possono essere utilizzate da un server di origine o da un intermediario in una risposta HTTP.
5.2.2.1. must-revalidate
La direttiva di risposta "must-revalidate" indica che una volta che la risposta è diventata obsoleta, una cache NON DEVE (MUST NOT) utilizzare la risposta per soddisfare richieste successive senza una validazione riuscita sul server di origine.
La direttiva must-revalidate è necessaria per supportare il funzionamento affidabile di determinate funzionalità del protocollo. In tutte le circostanze, una cache DEVE (MUST) obbedire alla direttiva must-revalidate; in particolare, se una cache non può raggiungere il server di origine per qualsiasi motivo, DEVE (MUST) generare una risposta 504 (Gateway Timeout).
La direttiva must-revalidate dovrebbe (ought to) essere utilizzata dai server se e solo se il mancato successo della validazione di una richiesta potrebbe comportare un funzionamento errato, come una transazione finanziaria silenziosamente non eseguita.
5.2.2.2. no-cache
Argomento: #field-name (opzionale)
La direttiva di risposta "no-cache" indica che la risposta NON DEVE (MUST NOT) essere utilizzata per soddisfare una richiesta successiva senza una validazione riuscita sul server di origine. Ciò consente a un server di origine di impedire a una cache di utilizzare la risposta per soddisfare una richiesta senza contattarlo, anche da parte di cache che sono state configurate per inviare risposte obsolete.
Se la direttiva di risposta no-cache specifica uno o più nomi di campo, allora una cache PUÒ (MAY) utilizzare la risposta per soddisfare una richiesta successiva, soggetta a qualsiasi altra restrizione sul caching. Tuttavia, qualsiasi nome di campo specificato NON DEVE (MUST NOT) essere inviato nella risposta a una richiesta successiva senza una rivalidazione riuscita con il server di origine. Ciò consente a un server di origine di impedire il riutilizzo di determinati campi di intestazione in una risposta, pur consentendo il caching del resto della risposta.
Nota: La maggior parte delle cache HTTP/1.0 non riconoscerà o obbedirà a questa direttiva. Inoltre, le direttive di risposta no-cache con nomi di campo vengono spesso gestite dalle implementazioni come se fosse stata ricevuta una direttiva no-cache non qualificata; cioè, la gestione speciale per la forma qualificata non è ampiamente implementata.
5.2.2.3. no-store
La direttiva di risposta "no-store" indica che una cache NON DEVE (MUST NOT) memorizzare alcuna parte né della richiesta immediata né della risposta. Questa direttiva si applica sia alle cache private che a quelle condivise. "NON DEVE memorizzare" in questo contesto significa che la cache NON DEVE (MUST NOT) intenzionalmente memorizzare le informazioni in una memoria non volatile, e DEVE (MUST) fare un tentativo del miglior sforzo per rimuovere le informazioni dalla memoria volatile il più prontamente possibile dopo averle inoltrate.
Questa direttiva NON è un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache malevole o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni.
5.2.2.4. no-transform
La direttiva di risposta "no-transform" indica che un intermediario (indipendentemente dal fatto che implementi o meno una cache) NON DEVE (MUST NOT) trasformare il payload, come definito nella Sezione 5.7.2 di [RFC7230].
5.2.2.5. public
La direttiva di risposta "public" indica che qualsiasi cache PUÒ (MAY) memorizzare la risposta, anche se la risposta normalmente non sarebbe memorizzabile in cache o memorizzabile in cache solo all'interno di una cache privata. (Vedere anche la Sezione 3.2, che discute dell'effetto del campo di intestazione Authorization sulla memorizzabilità in cache.)
5.2.2.6. private
Argomento: #field-name (opzionale)
La direttiva di risposta "private" indica che la risposta è destinata a un singolo utente e NON DEVE (MUST NOT) essere memorizzata da una cache condivisa. Una cache privata PUÒ (MAY) memorizzare la risposta e riutilizzarla per richieste successive, anche se la risposta normalmente non sarebbe memorizzabile in cache.
Se la direttiva di risposta private specifica uno o più nomi di campo, questo requisito è limitato ai valori di campo associati ai campi di intestazione di risposta elencati. Cioè, una cache condivisa NON DEVE (MUST NOT) memorizzare i nomi di campo specificati, mentre PUÒ (MAY) memorizzare il resto del messaggio di risposta.
Nota: Questa direttiva non è un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache malevole o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni.
5.2.2.7. proxy-revalidate
La direttiva di risposta "proxy-revalidate" ha lo stesso significato della direttiva di risposta must-revalidate, tranne per il fatto che non si applica alle cache private.
5.2.2.8. max-age
Argomento: delta-seconds
La direttiva di risposta "max-age" indica che la risposta deve essere considerata obsoleta dopo che la sua età è maggiore del numero di secondi specificato.
Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 'max-age=5' non 'max-age="5"'. Un mittente NON DOVREBBE (SHOULD NOT) generare la forma di stringa tra virgolette.
5.2.2.9. s-maxage
Argomento: delta-seconds
La direttiva di risposta "s-maxage" indica che, nelle cache condivise, l'età massima specificata da questa direttiva sovrascrive l'età massima specificata sia dalla direttiva max-age che dal campo di intestazione Expires. La direttiva s-maxage implica anche la semantica della direttiva di risposta proxy-revalidate.
Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 's-maxage=10' non 's-maxage="10"'. Un mittente NON DOVREBBE (SHOULD NOT) generare la forma di stringa tra virgolette.
📝 翻译说明 (Translation Notes)
- 5.2.2核心响应指令: 这九个指令是HTTP缓存服务器端控制的完整体系
- must-revalidate: 金融级可靠性要求在所有语言中都得到了强调，包括504响应的强制规定
- no-cache vs no-store: 两者在所有语言中都明确区分了验证要求和存储禁止
- no-cache可选字段名: 字段级缓存控制的复杂性在所有语言版本中得到了准确传达
- public vs private: 共享/私有缓存的区别在所有语言中保持了法律级精确性
- proxy-revalidate vs must-revalidate: 对私有缓存的豁免在所有语言版本中得到了清晰说明
- s-maxage: 共享缓存优先级和隐含proxy-revalidate的规则在所有语言中准确翻译
- 隐私警告: 所有涉及隐私的指令（no-store、private）都在所有语言版本中包含了"不是可靠机制"的警告
- HTTP/1.0兼容性: no-cache的历史兼容性问题在所有语言版本中得到了准确说明