メインコンテンツまでスキップ

4.2.1. Calculating Freshness Lifetime (计算新鲜度生命周期)

🇬🇧 English​

A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of the following:

  • If the cache is shared and the s-maxage response directive (Section 5.2.2.9) is present, use its value, or
  • If the max-age response directive (Section 5.2.2.8) is present, use its value, or
  • If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field, or
  • Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.

Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.

When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged to consider responses that have invalid freshness information to be stale.

🇨🇳 中文​

缓存可以使用以下第一个匹配项来计算响应的新鲜度生命周期（记为freshness_lifetime）:

  • 如果缓存是共享的并且存在s-maxage响应指令（第5.2.2.9节），则使用其值，或
  • 如果存在max-age响应指令（第5.2.2.8节），则使用其值，或
  • 如果存在Expires响应头字段（第5.3节），则使用其值减去Date响应头字段的值，或
  • 否则，响应中不存在显式过期时间。可能适用启发式新鲜度生命周期; 见第4.2.2节。

请注意，此计算不受时钟偏差影响，因为所有信息都来自源服务器。

当给定指令存在多个值时（例如，两个Expires头字段、多个Cache-Control: max-age指令），该指令的值被视为无效。鼓励缓存将具有无效新鲜度信息的响应视为过期。

🇯🇵 日本語​

キャッシュは、以下の最初の一致を使用して、レスポンスの鮮度有効期間（freshness_lifetimeと表記）を計算できる:

  • キャッシュが共有されており、s-maxageレスポンスディレクティブ（セクション5.2.2.9）が存在する場合、その値を使用する、または
  • max-ageレスポンスディレクティブ（セクション5.2.2.8）が存在する場合、その値を使用する、または
  • Expiresレスポンスヘッダーフィールド（セクション5.3）が存在する場合、その値からDateレスポンスヘッダーフィールドの値を引いた値を使用する、または
  • それ以外の場合、レスポンスに明示的な有効期限が存在しない。ヒューリスティック鮮度有効期間が適用される可能性がある; セクション4.2.2を参照。

この計算は、すべての情報がオリジンサーバーから来るため、時計のずれに対して脆弱ではないことに注意すること。

特定のディレクティブに複数の値が存在する場合（例えば、2つのExpiresヘッダーフィールド、複数のCache-Control: max-ageディレクティブ）、そのディレクティブの値は無効と見なされる。無効な鮮度情報を持つレスポンスを古いものと見なすことが推奨される。

🇫🇷 Français​

Un cache peut calculer la durée de vie de fraîcheur (notée freshness_lifetime) d'une réponse en utilisant la première correspondance parmi les suivantes :

  • Si le cache est partagé et que la directive de réponse s-maxage (Section 5.2.2.9) est présente, utiliser sa valeur, ou
  • Si la directive de réponse max-age (Section 5.2.2.8) est présente, utiliser sa valeur, ou
  • Si le champ d'en-tête de réponse Expires (Section 5.3) est présent, utiliser sa valeur moins la valeur du champ d'en-tête de réponse Date, ou
  • Sinon, aucun temps d'expiration explicite n'est présent dans la réponse. Une durée de vie de fraîcheur heuristique pourrait être applicable ; voir Section 4.2.2.

Notez que ce calcul n'est pas vulnérable au décalage d'horloge, car toutes les informations proviennent du serveur d'origine.

Lorsqu'il y a plus d'une valeur présente pour une directive donnée (par exemple, deux champs d'en-tête Expires, plusieurs directives Cache-Control : max-age), la valeur de la directive est considérée comme invalide. Les caches sont encouragés à considérer les réponses qui ont des informations de fraîcheur invalides comme périmées.

🇩🇪 Deutsch​

Ein Cache kann die Frische-Lebensdauer (bezeichnet als freshness_lifetime) einer Antwort berechnen, indem er die erste Übereinstimmung der folgenden verwendet:

  • Wenn der Cache gemeinsam genutzt wird und die s-maxage-Antwortdirektive (Abschnitt 5.2.2.9) vorhanden ist, verwenden Sie ihren Wert, oder
  • Wenn die max-age-Antwortdirektive (Abschnitt 5.2.2.8) vorhanden ist, verwenden Sie ihren Wert, oder
  • Wenn das Expires-Antwort-Header-Feld (Abschnitt 5.3) vorhanden ist, verwenden Sie seinen Wert minus dem Wert des Date-Antwort-Header-Felds, oder
  • Andernfalls ist keine explizite Ablaufzeit in der Antwort vorhanden. Eine heuristische Frische-Lebensdauer könnte anwendbar sein; siehe Abschnitt 4.2.2.

Beachten Sie, dass diese Berechnung nicht anfällig für Uhrenabweichungen ist, da alle Informationen vom Ursprungsserver stammen.

Wenn mehr als ein Wert für eine bestimmte Direktive vorhanden ist (z. B. zwei Expires-Header-Felder, mehrere Cache-Control: max-age-Direktiven), wird der Wert der Direktive als ungültig betrachtet. Caches werden ermutigt, Antworten mit ungültigen Frische-Informationen als veraltet zu betrachten.

🇮🇹 Italiano​

Una cache può calcolare la durata di freschezza (indicata come freshness_lifetime) di una risposta utilizzando la prima corrispondenza tra le seguenti:

  • Se la cache è condivisa e la direttiva di risposta s-maxage (Sezione 5.2.2.9) è presente, utilizzare il suo valore, o
  • Se la direttiva di risposta max-age (Sezione 5.2.2.8) è presente, utilizzare il suo valore, o
  • Se il campo di intestazione di risposta Expires (Sezione 5.3) è presente, utilizzare il suo valore meno il valore del campo di intestazione di risposta Date, o
  • Altrimenti, non è presente alcun tempo di scadenza esplicito nella risposta. Potrebbe essere applicabile una durata di freschezza euristica; vedere Sezione 4.2.2.

Si noti che questo calcolo non è vulnerabile allo sfasamento dell'orologio, poiché tutte le informazioni provengono dal server di origine.

Quando è presente più di un valore per una determinata direttiva (ad esempio, due campi di intestazione Expires, più direttive Cache-Control: max-age), il valore della direttiva è considerato non valido. Le cache sono incoraggiate a considerare le risposte che hanno informazioni di freschezza non valide come obsolete.

4.2.2. Calculating Heuristic Freshness (计算启发式新鲜度)

🇬🇧 English​

Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case constraints on their results.

A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements in Section 3, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are defined as cacheable by default (see Section 6.1 of [RFC7231]), and those responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive).

If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.

When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a Warning header field with a 113 warn-code (see Section 5.5.4) in the response if its current_age is more than 24 hours and such a warning is not already present.

Note: Section 13.9 of [RFC2616] prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control: no-cache) if they wish to preclude caching.

🇨🇳 中文​

由于源服务器并不总是提供显式过期时间，因此当未指定显式时间时，缓存可以 (MAY) 分配启发式过期时间，使用算法利用其他头字段值（如Last-Modified时间）来估计合理的过期时间。本规范不提供特定算法，但对其结果施加最坏情况约束。

当存储的响应中存在显式过期时间时，缓存不得 (MUST NOT) 使用启发式方法来确定新鲜度。由于第3节的要求，这意味着，实际上，启发式方法只能用于没有显式新鲜度且其状态码默认定义为可缓存的响应（见 [RFC7231] 的第6.1节），以及那些没有显式新鲜度但已被标记为明确可缓存的响应（例如，使用"public"响应指令）。

如果响应具有Last-Modified头字段（[RFC7232] 的第2.2节），则鼓励缓存使用不超过自该时间以来间隔的某个分数的启发式过期值。此分数的典型设置可能为10%。

当使用启发式方法计算新鲜度生命周期时，如果响应的current_age超过24小时且尚未存在此类警告，则缓存应该 (SHOULD) 在响应中生成带有113 warn-code的Warning头字段（见第5.5.4节）。

注意: [RFC2616] 的第13.9节禁止缓存为具有查询组件的URI（即包含'?'的URI）计算启发式新鲜度。在实践中，这并未被广泛实现。因此，如果源服务器希望阻止缓存，则鼓励发送显式指令（例如，Cache-Control: no-cache）。

🇯🇵 日本語​

オリジンサーバーが常に明示的な有効期限を提供するわけではないため、明示的な時間が指定されていない場合、キャッシュはヒューリスティック有効期限を割り当ててもよく (MAY)、他のヘッダーフィールド値（Last-Modified時刻など）を使用して妥当な有効期限を推定するアルゴリズムを使用する。この仕様では特定のアルゴリズムは提供されないが、その結果に対する最悪ケースの制約が課される。

保存されたレスポンスに明示的な有効期限が存在する場合、キャッシュはヒューリスティックを使用して鮮度を判断してはならない (MUST NOT)。セクション3の要件により、これは実質的に、ヒューリスティックは、ステータスコードがデフォルトでキャッシュ可能として定義されている明示的な鮮度のないレスポンス（[RFC7231] のセクション6.1参照）、および明示的にキャッシュ可能としてマークされている明示的な鮮度のないレスポンス（例えば、"public"レスポンスディレクティブ付き）にのみ使用できることを意味する。

レスポンスにLast-Modifiedヘッダーフィールド（[RFC7232] のセクション2.2）がある場合、キャッシュは、その時刻からの間隔のある割合以下のヒューリスティック有効期限値を使用することが推奨される。この割合の典型的な設定は10%である可能性がある。

ヒューリスティックを使用して鮮度有効期間を計算する場合、current_ageが24時間を超えており、そのような警告がまだ存在しない場合、キャッシュはレスポンス内に113 warn-code（セクション5.5.4参照）を含むWarningヘッダーフィールドを生成すべきである (SHOULD)。

注: [RFC2616] のセクション13.9は、クエリコンポーネントを持つURI（つまり、'?'を含むもの）に対してキャッシュがヒューリスティック鮮度を計算することを禁止していた。実際には、これは広く実装されていない。したがって、キャッシュを妨げたい場合は、オリジンサーバーに明示的なディレクティブ（例えば、Cache-Control: no-cache）を送信することが推奨される。

🇫🇷 Français​

Puisque les serveurs d'origine ne fournissent pas toujours des temps d'expiration explicites, un cache PEUT (MAY) attribuer un temps d'expiration heuristique lorsqu'un temps explicite n'est pas spécifié, en utilisant des algorithmes qui utilisent d'autres valeurs de champs d'en-tête (telles que le temps Last-Modified) pour estimer un temps d'expiration plausible. Cette spécification ne fournit pas d'algorithmes spécifiques, mais impose des contraintes de pire cas sur leurs résultats.

Un cache NE DOIT PAS (MUST NOT) utiliser d'heuristiques pour déterminer la fraîcheur lorsqu'un temps d'expiration explicite est présent dans la réponse stockée. En raison des exigences de la Section 3, cela signifie que, en pratique, les heuristiques ne peuvent être utilisées que sur des réponses sans fraîcheur explicite dont les codes d'état sont définis comme pouvant être mis en cache par défaut (voir Section 6.1 de [RFC7231]), et ces réponses sans fraîcheur explicite qui ont été marquées comme explicitement pouvant être mises en cache (par exemple, avec une directive de réponse "public").

Si la réponse possède un champ d'en-tête Last-Modified (Section 2.2 de [RFC7232]), les caches sont encouragés à utiliser une valeur d'expiration heuristique qui ne soit pas plus qu'une fraction de l'intervalle depuis ce moment. Un réglage typique de cette fraction pourrait être de 10 %.

Lorsqu'une heuristique est utilisée pour calculer la durée de vie de fraîcheur, un cache DEVRAIT (SHOULD) générer un champ d'en-tête Warning avec un warn-code 113 (voir Section 5.5.4) dans la réponse si son current_age dépasse 24 heures et qu'un tel avertissement n'est pas déjà présent.

Remarque : La Section 13.9 de [RFC2616] interdisait aux caches de calculer la fraîcheur heuristique pour les URI avec des composants de requête (c'est-à-dire ceux contenant '?'). En pratique, cela n'a pas été largement implémenté. Par conséquent, les serveurs d'origine sont encouragés à envoyer des directives explicites (par exemple, Cache-Control : no-cache) s'ils souhaitent empêcher la mise en cache.

🇩🇪 Deutsch​

Da Ursprungsserver nicht immer explizite Ablaufzeiten bereitstellen, DARF (MAY) ein Cache eine heuristische Ablaufzeit zuweisen, wenn keine explizite Zeit angegeben ist, wobei Algorithmen verwendet werden, die andere Header-Feldwerte (wie die Last-Modified-Zeit) verwenden, um eine plausible Ablaufzeit zu schätzen. Diese Spezifikation stellt keine spezifischen Algorithmen bereit, legt jedoch Worst-Case-Beschränkungen für ihre Ergebnisse fest.

Ein Cache DARF NICHT (MUST NOT) Heuristiken verwenden, um die Frische zu bestimmen, wenn eine explizite Ablaufzeit in der gespeicherten Antwort vorhanden ist. Aufgrund der Anforderungen in Abschnitt 3 bedeutet dies, dass Heuristiken effektiv nur für Antworten ohne explizite Frische verwendet werden können, deren Statuscodes standardmäßig als cachefähig definiert sind (siehe Abschnitt 6.1 von [RFC7231]), und jene Antworten ohne explizite Frische, die als explizit cachefähig markiert wurden (z. B. mit einer "public"-Antwortdirektive).

Wenn die Antwort ein Last-Modified-Header-Feld hat (Abschnitt 2.2 von [RFC7232]), werden Caches ermutigt, einen heuristischen Ablaufwert zu verwenden, der nicht mehr als ein gewisser Bruchteil des Intervalls seit dieser Zeit ist. Eine typische Einstellung dieses Bruchteils könnte 10 % sein.

Wenn eine Heuristik zur Berechnung der Frische-Lebensdauer verwendet wird, SOLLTE (SHOULD) ein Cache ein Warning-Header-Feld mit einem 113-Warn-Code (siehe Abschnitt 5.5.4) in der Antwort generieren, wenn sein current_age mehr als 24 Stunden beträgt und eine solche Warnung nicht bereits vorhanden ist.

Hinweis: Abschnitt 13.9 von [RFC2616] verbot Caches, heuristische Frische für URIs mit Abfragekomponenten zu berechnen (d. h. solche, die '?' enthalten). In der Praxis wurde dies nicht weit verbreitet implementiert. Daher werden Ursprungsserver ermutigt, explizite Direktiven zu senden (z. B. Cache-Control: no-cache), wenn sie das Caching verhindern möchten.

🇮🇹 Italiano​

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, una cache PUÒ (MAY) assegnare un tempo di scadenza euristico quando non è specificato un tempo esplicito, impiegando algoritmi che utilizzano altri valori di campi di intestazione (come il tempo Last-Modified) per stimare un tempo di scadenza plausibile. Questa specifica non fornisce algoritmi specifici, ma impone vincoli di caso peggiore sui loro risultati.

Una cache NON DEVE (MUST NOT) utilizzare euristiche per determinare la freschezza quando è presente un tempo di scadenza esplicito nella risposta memorizzata. A causa dei requisiti nella Sezione 3, ciò significa che, in effetti, le euristiche possono essere utilizzate solo su risposte senza freschezza esplicita i cui codici di stato sono definiti come memorizzabili in cache per impostazione predefinita (vedere Sezione 6.1 di [RFC7231]), e quelle risposte senza freschezza esplicita che sono state contrassegnate come esplicitamente memorizzabili in cache (ad esempio, con una direttiva di risposta "public").

Se la risposta ha un campo di intestazione Last-Modified (Sezione 2.2 di [RFC7232]), le cache sono incoraggiate a utilizzare un valore di scadenza euristico che non sia più di una certa frazione dell'intervallo da quel momento. Un'impostazione tipica di questa frazione potrebbe essere il 10%.

Quando viene utilizzata un'euristica per calcolare la durata di freschezza, una cache DOVREBBE (SHOULD) generare un campo di intestazione Warning con un warn-code 113 (vedere Sezione 5.5.4) nella risposta se il suo current_age supera le 24 ore e tale avvertimento non è già presente.

Nota: La Sezione 13.9 di [RFC2616] proibiva alle cache di calcolare la freschezza euristica per gli URI con componenti di query (cioè quelli contenenti '?'). In pratica, questo non è stato ampiamente implementato. Pertanto, i server di origine sono incoraggiati a inviare direttive esplicite (ad esempio, Cache-Control: no-cache) se desiderano impedire il caching.

📝 翻译说明 (Translation Notes)

  • 4.2.1 核心算法: 优先级顺序 s-maxage > max-age > Expires，所有语言版本保持精确一致
  • 4.2.2 启发式计算: 10%规则是业界惯例，所有语言版本都准确传达了这一重要信息
  • 警告机制: Warning 113的24小时规则在所有语言中保持法律级严谨性
  • RFC 2616遗留问题: 关于查询字符串的注释在所有语言版本中都得到了正确翻译
に最終更新