2. Overview of Cache Operation (缓存操作概述)
🇬🇧 English
Proper cache operation preserves the semantics of HTTP transfers while reducing the transmission of information already held in the cache. See Section 3 for details of how a cache can determine what responses are cacheable and Section 4 for details of constructing responses from cache entries. This section provides an overview of how caches select and update stored responses.
Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.
The query component of a request target (Section 5.3 of [RFC7230]) can contain information about the request that is specific to one user, a cohort of users, or the user's current state. In general, it is not safe for a cache to reuse a response to a request with a query component to satisfy that same request from another user, since the users might have different query values in their requests even if the path portions are the same. A cache recipient receiving a successful response with a query component in the request target SHOULD NOT reuse that response for a request with a different query component, unless the response explicitly allows it with Cache-Control directives (Section 5.2).
A cache can store and reuse a response to a request with a query component if the response is explicitly allowed by Cache-Control directives or the response contains a validator (Section 2.3 of [RFC7232]) and the cache follows the validation requirements. When this happens, a cache MAY use that response to satisfy a different request, subject to the constraint that the cache key matches (Section 4.1), all applicable freshness requirements are met (Section 4.2), and any applicable cache requirements imposed by the request and the stored response are met.
Various mechanisms exist by which a cache can learn about a cached response's current validity. A cached response is "fresh" if its age has not yet exceeded its freshness lifetime. Conversely, a cached response is "stale" if it has been in cache long enough to meet or pass its freshness lifetime.
A fresh response can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency. The protocol includes mechanisms for an origin server to assign an explicit freshness lifetime, the calculation of a heuristic freshness lifetime when an explicit one is not set, and a mechanism for validating a cached response to extend its freshness lifetime after it has become stale.
The primary mechanism for assigning freshness is for an origin server to send an explicit expiration time via either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.8). Generally, origin servers will assign an explicit expiration time that is sufficient to satisfy all expected uses of the response. A liberal lifetime can be given to allow for frequent reuse by caches; a conservative lifetime can be given if content is known to vary on a regular basis.
When an explicit expiration time is not present, a cache MAY calculate a heuristic expiration time. A cache MUST NOT use heuristic expiration times for responses with status codes whose cacheability is not defined by this specification, such as redirects other than 300, 301, or 308 (see Section 6 of [RFC7231]), or when the status code indicates an error (i.e., the status code is greater than or equal to 400).
When a stored response is stale, a cache typically uses validation (conditional requests as defined in [RFC7232]) to update the stored response and avoid transferring the representation data unnecessarily. A stale response can still be used, without validation, if the disconnected operation is permitted by the cache's configuration or the request directives in Cache-Control allow it (Section 5.2).
🇨🇳 中文
正确的缓存操作在减少传输已在缓存中保存的信息的同时，保留HTTP传输的语义。有关缓存如何确定哪些响应可缓存的详细信息，请参见第3节；有关从缓存条目构建响应的详细信息，请参见第4节。本节概述缓存如何选择和更新存储的响应。
尽管缓存是HTTP的完全可选 (OPTIONAL) 功能，但可以假设重用缓存的响应是可取的，并且在没有要求或本地配置阻止的情况下，这种重用是默认行为。因此，HTTP缓存要求侧重于防止缓存存储不可重用的响应或不当地重用存储的响应，而不是强制缓存始终存储和重用特定响应。
请求目标的查询组件 (Query Component)（[RFC7230] 的第5.3节）可以包含特定于一个用户、一组用户或用户当前状态的请求信息。一般来说，缓存重用带有查询组件的请求的响应来满足来自另一个用户的相同请求是不安全的，因为即使路径部分相同，用户的请求中也可能具有不同的查询值。接收到请求目标中带有查询组件的成功响应的缓存接收者不应 (SHOULD NOT) 为具有不同查询组件的请求重用该响应，除非响应通过Cache-Control指令（第5.2节）明确允许。
如果响应被Cache-Control指令明确允许，或者响应包含验证器 (Validator)（[RFC7232] 的第2.3节）并且缓存遵循验证要求，则缓存可以存储和重用带有查询组件的请求的响应。在这种情况下，缓存可以 (MAY) 使用该响应来满足不同的请求，但须遵守以下约束: 缓存键匹配（第4.1节）、满足所有适用的新鲜度要求（第4.2节）以及满足请求和存储的响应施加的任何适用缓存要求。
缓存可以通过各种机制了解缓存响应的当前有效性。如果缓存响应的年龄尚未超过其新鲜度生命周期 (Freshness Lifetime)，则该响应是"新鲜的" (Fresh)。相反，如果缓存响应在缓存中的时间足够长，达到或超过其新鲜度生命周期，则该响应是"过期的" (Stale)。
新鲜的响应可以用于满足后续请求，而无需联系源服务器，从而提高效率。该协议包括以下机制: 源服务器分配显式新鲜度生命周期的机制、在未设置显式生命周期时计算启发式新鲜度生命周期的机制，以及在缓存响应变得过期后通过验证来延长其新鲜度生命周期的机制。
分配新鲜度的主要机制是源服务器通过Expires头字段（第5.3节）或max-age响应指令（第5.2.2.8节）发送显式过期时间。通常，源服务器会分配足以满足响应的所有预期用途的显式过期时间。可以给出宽松的生命周期以允许缓存频繁重用; 如果已知内容定期变化，则可以给出保守的生命周期。
当不存在显式过期时间时，缓存可以 (MAY) 计算启发式过期时间。缓存不得 (MUST NOT) 对本规范未定义其可缓存性的状态码的响应使用启发式过期时间，例如除300、301或308之外的重定向（请参见 [RFC7231] 的第6节），或者当状态码指示错误时（即，状态码大于或等于400）。
当存储的响应过期时，缓存通常使用验证（[RFC7232] 中定义的条件请求）来更新存储的响应，并避免不必要地传输表示数据。如果缓存的配置允许断开连接的操作，或者Cache-Control中的请求指令允许（第5.2节），则过期的响应仍然可以在没有验证的情况下使用。
🇯🇵 日本語
適切なキャッシュ操作は、キャッシュにすでに保持されている情報の送信を削減しながら、HTTP転送のセマンティクスを保持する。キャッシュがどのレスポンスをキャッシュ可能と判断できるかの詳細については第3節を、キャッシュエントリからレスポンスを構築する詳細については第4節を参照。本節は、キャッシュが保存されたレスポンスを選択および更新する方法の概要を提供する。
キャッシュはHTTPの完全にオプション (OPTIONAL) な機能であるが、キャッシュされたレスポンスの再利用が望ましいこと、および要件またはローカル設定がそれを妨げない場合、そのような再利用がデフォルトの動作であることを前提とすることができる。したがって、HTTPキャッシュ要件は、キャッシュが特定のレスポンスを常に保存および再利用することを義務付けるのではなく、キャッシュが再利用不可能なレスポンスを保存すること、または保存されたレスポンスを不適切に再利用することを防ぐことに焦点を当てている。
リクエストターゲットのクエリコンポーネント (Query Component)（[RFC7230] のセクション5.3）には、1人のユーザー、ユーザーのコホート、またはユーザーの現在の状態に固有のリクエストに関する情報を含めることができる。一般に、パス部分が同じであっても、ユーザーのリクエストに異なるクエリ値がある可能性があるため、キャッシュがクエリコンポーネントを含むリクエストへのレスポンスを別のユーザーからの同じリクエストを満たすために再利用することは安全ではない。リクエストターゲットにクエリコンポーネントを含む成功したレスポンスを受信するキャッシュ受信者は、レスポンスがCache-Controlディレクティブ（セクション5.2）で明示的に許可しない限り、異なるクエリコンポーネントを持つリクエストに対してそのレスポンスを再利用すべきではない (SHOULD NOT)。
キャッシュは、レスポンスがCache-Controlディレクティブによって明示的に許可されている場合、またはレスポンスがバリデータ (Validator)（[RFC7232] のセクション2.3）を含み、キャッシュが検証要件に従う場合、クエリコンポーネントを含むリクエストへのレスポンスを保存および再利用できる。これが発生した場合、キャッシュキーが一致し（セクション4.1）、すべての適用可能な鮮度要件が満たされ（セクション4.2）、リクエストおよび保存されたレスポンスによって課されるすべての適用可能なキャッシュ要件が満たされるという制約の下で、キャッシュはそのレスポンスを使用して別のリクエストを満たすことができる (MAY)。
キャッシュされたレスポンスの現在の有効性について、キャッシュが学習できるさまざまなメカニズムが存在する。キャッシュされたレスポンスは、その経過時間 (Age) がまだ鮮度有効期間 (Freshness Lifetime) を超えていない場合、「新鮮」(Fresh) である。逆に、キャッシュされたレスポンスは、鮮度有効期間を満たすか超えるのに十分な時間キャッシュに存在していた場合、「古い」(Stale) である。
新鮮なレスポンスは、オリジンサーバーに接触することなく後続のリクエストを満たすために使用でき、効率を向上させる。プロトコルには、オリジンサーバーが明示的な鮮度有効期間を割り当てるメカニズム、明示的な鮮度有効期間が設定されていない場合にヒューリスティック鮮度有効期間を計算するメカニズム、およびキャッシュされたレスポンスが古くなった後に検証してその鮮度有効期間を延長するメカニズムが含まれている。
鮮度を割り当てる主要なメカニズムは、オリジンサーバーがExpiresヘッダーフィールド（セクション5.3）またはmax-ageレスポンスディレクティブ（セクション5.2.2.8）を介して明示的な有効期限を送信することである。一般に、オリジンサーバーは、レスポンスのすべての予想される使用を満たすのに十分な明示的な有効期限を割り当てる。キャッシュによる頻繁な再利用を許可するために寛大な有効期間を与えることができる; コンテンツが定期的に変化することがわかっている場合は、保守的な有効期間を与えることができる。
明示的な有効期限が存在しない場合、キャッシュはヒューリスティック有効期限を計算してもよい (MAY)。キャッシュは、本仕様でキャッシュ可能性が定義されていないステータスコードのレスポンスに対して、300、301、または308以外のリダイレクト（[RFC7231] のセクション6を参照）など、またはステータスコードがエラーを示す場合（つまり、ステータスコードが400以上である場合）、ヒューリスティック有効期限を使用してはならない (MUST NOT)。
保存されたレスポンスが古い場合、キャッシュは通常、検証（[RFC7232] で定義されている条件付きリクエスト）を使用して保存されたレスポンスを更新し、表現データの不必要な転送を回避する。古いレスポンスは、キャッシュの設定によって切断された操作が許可されている場合、またはCache-Controlのリクエストディレクティブがそれを許可している場合（セクション5.2）、検証なしでも使用できる。
🇫🇷 Français
Un fonctionnement correct du cache préserve la sémantique des transferts HTTP tout en réduisant la transmission d'informations déjà détenues dans le cache. Voir la Section 3 pour les détails sur la façon dont un cache peut déterminer quelles réponses sont mises en cache et la Section 4 pour les détails sur la construction de réponses à partir d'entrées de cache. Cette section fournit un aperçu de la manière dont les caches sélectionnent et mettent à jour les réponses stockées.
Bien que la mise en cache soit une fonctionnalité entièrement OPTIONNELLE (OPTIONAL) de HTTP, on peut supposer que la réutilisation d'une réponse mise en cache est souhaitable et que cette réutilisation est le comportement par défaut lorsqu'aucune exigence ou configuration locale ne l'empêche. Par conséquent, les exigences de cache HTTP se concentrent sur la prévention du stockage par un cache d'une réponse non réutilisable ou de la réutilisation inappropriée d'une réponse stockée, plutôt que d'imposer aux caches de toujours stocker et réutiliser des réponses particulières.
Le composant de requête (Query Component) d'une cible de requête (Section 5.3 de [RFC7230]) peut contenir des informations sur la requête spécifiques à un utilisateur, une cohorte d'utilisateurs ou l'état actuel de l'utilisateur. En général, il n'est pas sûr pour un cache de réutiliser une réponse à une requête avec un composant de requête pour satisfaire cette même requête d'un autre utilisateur, car les utilisateurs peuvent avoir des valeurs de requête différentes dans leurs requêtes même si les portions de chemin sont identiques. Un destinataire de cache recevant une réponse réussie avec un composant de requête dans la cible de requête NE DEVRAIT PAS (SHOULD NOT) réutiliser cette réponse pour une requête avec un composant de requête différent, à moins que la réponse ne l'autorise explicitement avec des directives Cache-Control (Section 5.2).
Un cache peut stocker et réutiliser une réponse à une requête avec un composant de requête si la réponse est explicitement autorisée par des directives Cache-Control ou si la réponse contient un validateur (Validator) (Section 2.3 de [RFC7232]) et que le cache suit les exigences de validation. Lorsque cela se produit, un cache PEUT (MAY) utiliser cette réponse pour satisfaire une requête différente, sous réserve de la contrainte que la clé de cache corresponde (Section 4.1), que toutes les exigences de fraîcheur applicables soient satisfaites (Section 4.2) et que toutes les exigences de cache applicables imposées par la requête et la réponse stockée soient satisfaites.
Divers mécanismes existent par lesquels un cache peut apprendre la validité actuelle d'une réponse mise en cache. Une réponse mise en cache est « fraîche » (Fresh) si son âge n'a pas encore dépassé sa durée de vie de fraîcheur (Freshness Lifetime). Inversement, une réponse mise en cache est « périmée » (Stale) si elle a été dans le cache suffisamment longtemps pour atteindre ou dépasser sa durée de vie de fraîcheur.
Une réponse fraîche peut être utilisée pour satisfaire des requêtes ultérieures sans contacter le serveur d'origine, améliorant ainsi l'efficacité. Le protocole inclut des mécanismes permettant à un serveur d'origine d'attribuer une durée de vie de fraîcheur explicite, le calcul d'une durée de vie de fraîcheur heuristique lorsqu'une durée explicite n'est pas définie, et un mécanisme de validation d'une réponse mise en cache pour prolonger sa durée de vie de fraîcheur après qu'elle soit devenue périmée.
Le mécanisme principal pour attribuer la fraîcheur est qu'un serveur d'origine envoie un temps d'expiration explicite via soit le champ d'en-tête Expires (Section 5.3), soit la directive de réponse max-age (Section 5.2.2.8). En général, les serveurs d'origine attribueront un temps d'expiration explicite suffisant pour satisfaire toutes les utilisations attendues de la réponse. Une durée de vie libérale peut être donnée pour permettre une réutilisation fréquente par les caches ; une durée de vie conservatrice peut être donnée si le contenu est connu pour varier régulièrement.
Lorsqu'un temps d'expiration explicite n'est pas présent, un cache PEUT (MAY) calculer un temps d'expiration heuristique. Un cache NE DOIT PAS (MUST NOT) utiliser des temps d'expiration heuristiques pour les réponses avec des codes d'état dont la mise en cache n'est pas définie par cette spécification, tels que les redirections autres que 300, 301 ou 308 (voir Section 6 de [RFC7231]), ou lorsque le code d'état indique une erreur (c'est-à-dire que le code d'état est supérieur ou égal à 400).
Lorsqu'une réponse stockée est périmée, un cache utilise généralement la validation (requêtes conditionnelles telles que définies dans [RFC7232]) pour mettre à jour la réponse stockée et éviter de transférer les données de représentation inutilement. Une réponse périmée peut toujours être utilisée, sans validation, si l'opération déconnectée est autorisée par la configuration du cache ou si les directives de requête dans Cache-Control le permettent (Section 5.2).
🇩🇪 Deutsch
Ein ordnungsgemäßer Cache-Betrieb bewahrt die Semantik von HTTP-Übertragungen, während die Übertragung von bereits im Cache gehaltenen Informationen reduziert wird. Siehe Abschnitt 3 für Details darüber, wie ein Cache bestimmen kann, welche Antworten cachefähig sind, und Abschnitt 4 für Details zum Konstruieren von Antworten aus Cache-Einträgen. Dieser Abschnitt bietet einen Überblick darüber, wie Caches gespeicherte Antworten auswählen und aktualisieren.
Obwohl Caching eine vollständig OPTIONALE (OPTIONAL) Funktion von HTTP ist, kann davon ausgegangen werden, dass die Wiederverwendung einer gecachten Antwort wünschenswert ist und dass eine solche Wiederverwendung das Standardverhalten ist, wenn keine Anforderung oder lokale Konfiguration dies verhindert. Daher konzentrieren sich die HTTP-Cache-Anforderungen darauf, zu verhindern, dass ein Cache eine nicht wiederverwendbare Antwort speichert oder eine gespeicherte Antwort unangemessen wiederverwendet, anstatt Caches zu verpflichten, immer bestimmte Antworten zu speichern und wiederzuverwenden.
Die Abfragekomponente (Query Component) eines Anfrageziels (Abschnitt 5.3 von [RFC7230]) kann Informationen über die Anfrage enthalten, die für einen Benutzer, eine Kohorte von Benutzern oder den aktuellen Zustand des Benutzers spezifisch sind. Im Allgemeinen ist es für einen Cache nicht sicher, eine Antwort auf eine Anfrage mit einer Abfragekomponente wiederzuverwenden, um dieselbe Anfrage von einem anderen Benutzer zu erfüllen, da die Benutzer möglicherweise unterschiedliche Abfragewerte in ihren Anfragen haben, selbst wenn die Pfadabschnitte gleich sind. Ein Cache-Empfänger, der eine erfolgreiche Antwort mit einer Abfragekomponente im Anfrageziel erhält, SOLLTE NICHT (SHOULD NOT) diese Antwort für eine Anfrage mit einer anderen Abfragekomponente wiederverwenden, es sei denn, die Antwort erlaubt dies explizit mit Cache-Control-Direktiven (Abschnitt 5.2).
Ein Cache kann eine Antwort auf eine Anfrage mit einer Abfragekomponente speichern und wiederverwenden, wenn die Antwort explizit durch Cache-Control-Direktiven zugelassen wird oder die Antwort einen Validator enthält (Abschnitt 2.3 von [RFC7232]) und der Cache den Validierungsanforderungen folgt. Wenn dies geschieht, DARF (MAY) ein Cache diese Antwort verwenden, um eine andere Anfrage zu erfüllen, vorbehaltlich der Einschränkung, dass der Cache-Schlüssel übereinstimmt (Abschnitt 4.1), alle anwendbaren Frische-Anforderungen erfüllt sind (Abschnitt 4.2) und alle anwendbaren Cache-Anforderungen, die von der Anfrage und der gespeicherten Antwort auferlegt werden, erfüllt sind.
Verschiedene Mechanismen existieren, durch die ein Cache über die aktuelle Gültigkeit einer gecachten Antwort lernen kann. Eine gecachte Antwort ist „frisch" (Fresh), wenn ihr Alter ihre Frische-Lebensdauer (Freshness Lifetime) noch nicht überschritten hat. Umgekehrt ist eine gecachte Antwort „veraltet" (Stale), wenn sie lange genug im Cache war, um ihre Frische-Lebensdauer zu erreichen oder zu überschreiten.
Eine frische Antwort kann verwendet werden, um nachfolgende Anfragen zu erfüllen, ohne den Ursprungsserver zu kontaktieren, wodurch die Effizienz verbessert wird. Das Protokoll umfasst Mechanismen, mit denen ein Ursprungsserver eine explizite Frische-Lebensdauer zuweisen kann, die Berechnung einer heuristischen Frische-Lebensdauer, wenn keine explizite festgelegt ist, und einen Mechanismus zur Validierung einer gecachten Antwort, um ihre Frische-Lebensdauer zu verlängern, nachdem sie veraltet ist.
Der primäre Mechanismus zur Zuweisung von Frische besteht darin, dass ein Ursprungsserver eine explizite Ablaufzeit entweder über das Expires-Header-Feld (Abschnitt 5.3) oder die max-age-Antwortdirektive (Abschnitt 5.2.2.8) sendet. Im Allgemeinen weisen Ursprungsserver eine explizite Ablaufzeit zu, die ausreicht, um alle erwarteten Verwendungen der Antwort zu erfüllen. Eine großzügige Lebensdauer kann gegeben werden, um eine häufige Wiederverwendung durch Caches zu ermöglichen; eine konservative Lebensdauer kann gegeben werden, wenn bekannt ist, dass sich der Inhalt regelmäßig ändert.
Wenn keine explizite Ablaufzeit vorhanden ist, DARF (MAY) ein Cache eine heuristische Ablaufzeit berechnen. Ein Cache DARF NICHT (MUST NOT) heuristische Ablaufzeiten für Antworten mit Statuscodes verwenden, deren Cachefähigkeit nicht durch diese Spezifikation definiert ist, wie z. B. Umleitungen außer 300, 301 oder 308 (siehe Abschnitt 6 von [RFC7231]), oder wenn der Statuscode einen Fehler anzeigt (d. h., der Statuscode ist größer oder gleich 400).
Wenn eine gespeicherte Antwort veraltet ist, verwendet ein Cache typischerweise Validierung (bedingte Anfragen, wie in [RFC7232] definiert), um die gespeicherte Antwort zu aktualisieren und die unnötige Übertragung von Darstellungsdaten zu vermeiden. Eine veraltete Antwort kann ohne Validierung weiterhin verwendet werden, wenn der getrennte Betrieb durch die Konfiguration des Caches zugelassen wird oder die Anfragedirektiven in Cache-Control dies zulassen (Abschnitt 5.2).
🇮🇹 Italiano
Un corretto funzionamento della cache preserva la semantica dei trasferimenti HTTP riducendo al contempo la trasmissione di informazioni già detenute nella cache. Vedere la Sezione 3 per i dettagli su come una cache può determinare quali risposte sono memorizzabili in cache e la Sezione 4 per i dettagli sulla costruzione di risposte da voci di cache. Questa sezione fornisce una panoramica di come le cache selezionano e aggiornano le risposte memorizzate.
Sebbene il caching sia una funzionalità interamente OPZIONALE (OPTIONAL) di HTTP, si può presumere che il riutilizzo di una risposta memorizzata in cache sia desiderabile e che tale riutilizzo sia il comportamento predefinito quando nessun requisito o configurazione locale lo impedisce. Pertanto, i requisiti della cache HTTP si concentrano sulla prevenzione del fatto che una cache memorizzi una risposta non riutilizzabile o riutilizzi in modo inappropriato una risposta memorizzata, piuttosto che imporre che le cache memorizzino e riutilizzino sempre particolari risposte.
Il componente di query (Query Component) di un target di richiesta (Sezione 5.3 di [RFC7230]) può contenere informazioni sulla richiesta specifiche per un utente, una coorte di utenti o lo stato corrente dell'utente. In generale, non è sicuro per una cache riutilizzare una risposta a una richiesta con un componente di query per soddisfare quella stessa richiesta da un altro utente, poiché gli utenti potrebbero avere valori di query diversi nelle loro richieste anche se le porzioni di percorso sono le stesse. Un destinatario di cache che riceve una risposta riuscita con un componente di query nel target della richiesta NON DOVREBBE (SHOULD NOT) riutilizzare quella risposta per una richiesta con un componente di query diverso, a meno che la risposta non lo consenta esplicitamente con direttive Cache-Control (Sezione 5.2).
Una cache può memorizzare e riutilizzare una risposta a una richiesta con un componente di query se la risposta è esplicitamente consentita da direttive Cache-Control o la risposta contiene un validatore (Validator) (Sezione 2.3 di [RFC7232]) e la cache segue i requisiti di validazione. Quando ciò accade, una cache PUÒ (MAY) utilizzare quella risposta per soddisfare una richiesta diversa, soggetta al vincolo che la chiave di cache corrisponda (Sezione 4.1), tutti i requisiti di freschezza applicabili siano soddisfatti (Sezione 4.2) e tutti i requisiti di cache applicabili imposti dalla richiesta e dalla risposta memorizzata siano soddisfatti.
Esistono vari meccanismi attraverso i quali una cache può apprendere la validità corrente di una risposta memorizzata in cache. Una risposta memorizzata in cache è "fresca" (Fresh) se la sua età non ha ancora superato la sua durata di freschezza (Freshness Lifetime). Al contrario, una risposta memorizzata in cache è "obsoleta" (Stale) se è stata nella cache abbastanza a lungo da soddisfare o superare la sua durata di freschezza.
Una risposta fresca può essere utilizzata per soddisfare richieste successive senza contattare il server di origine, migliorando così l'efficienza. Il protocollo include meccanismi per un server di origine per assegnare una durata di freschezza esplicita, il calcolo di una durata di freschezza euristica quando non ne è impostata una esplicita e un meccanismo per validare una risposta memorizzata in cache per estendere la sua durata di freschezza dopo che è diventata obsoleta.
Il meccanismo principale per assegnare la freschezza è che un server di origine invii un tempo di scadenza esplicito tramite il campo di intestazione Expires (Sezione 5.3) o la direttiva di risposta max-age (Sezione 5.2.2.8). In genere, i server di origine assegneranno un tempo di scadenza esplicito sufficiente per soddisfare tutti gli usi previsti della risposta. Una durata liberale può essere data per consentire un frequente riutilizzo da parte delle cache; una durata conservativa può essere data se il contenuto è noto per variare regolarmente.
Quando un tempo di scadenza esplicito non è presente, una cache PUÒ (MAY) calcolare un tempo di scadenza euristico. Una cache NON DEVE (MUST NOT) utilizzare tempi di scadenza euristici per risposte con codici di stato la cui memorizzabilità in cache non è definita da questa specifica, come reindirizzamenti diversi da 300, 301 o 308 (vedere Sezione 6 di [RFC7231]), o quando il codice di stato indica un errore (cioè, il codice di stato è maggiore o uguale a 400).
Quando una risposta memorizzata è obsoleta, una cache utilizza tipicamente la validazione (richieste condizionali come definite in [RFC7232]) per aggiornare la risposta memorizzata ed evitare di trasferire i dati di rappresentazione inutilmente. Una risposta obsoleta può ancora essere utilizzata, senza validazione, se l'operazione disconnessa è consentita dalla configurazione della cache o le direttive di richiesta in Cache-Control lo consentono (Sezione 5.2).
📝 翻译说明 (Translation Notes)
- 核心概念: Fresh (新鲜/新鮮/fraîche/frisch/fresca), Stale (过期/古い/périmée/veraltet/obsoleta), Freshness Lifetime (新鲜度生命周期/鮮度有効期間/durée de vie de fraîcheur/Frische-Lebensdauer/durata di freschezza) 等关键术语在各语言中保持一致性
- RFC 2119关键词: MUST, SHOULD, MAY等保留英文，符合RFC翻译规范
- 技术准确性: Query Component, Validator等专业术语采用双语标注以确保准确理解