Passa al contenuto principale

4.2. Freshness (新鲜度)

🇬🇧 English​

A fresh response is one whose age has not yet exceeded its freshness lifetime. Conversely, a stale response is one where it has.

A response's freshness lifetime is the length of time between its generation by the origin server and its expiration time. An explicit expiration time is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, whereas a heuristic expiration time is assigned by a cache when no explicit expiration time is available.

A response's age is the time that has passed since it was generated by, or successfully validated with, the origin server.

When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.

The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.8). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.

If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing it for subsequent requests (see Section 4.2.4).

Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine an expiration time under certain circumstances (see Section 4.2.2).

The calculation to determine if a response is fresh is:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime is defined in Section 4.2.1; current_age is defined in Section 4.2.3.

Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the corresponding response (Section 5.2.1).

When calculating freshness, to avoid common problems in date parsing:

  • Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match day, week, and time-zone names case-insensitively.
  • If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient MUST internally represent a parsed Expires date as the nearest time equal to or earlier than the received value.
  • A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
  • A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.

Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource. See Section 6 for an explanation of the difference between caches and history mechanisms.

🇨🇳 中文​

新鲜的响应是其年龄尚未超过其新鲜度生命周期的响应。相反，过期的响应是已经超过的响应。

响应的新鲜度生命周期 (Freshness Lifetime) 是从源服务器生成响应到其过期时间之间的时间长度。显式过期时间 (Explicit Expiration Time) 是源服务器打算在该时间之后缓存不能再使用存储的响应而不进行进一步验证的时间，而启发式过期时间 (Heuristic Expiration Time) 是在没有显式过期时间可用时由缓存分配的。

响应的年龄 (Age) 是自其由源服务器生成或成功验证以来经过的时间。

当响应在缓存中是"新鲜的"时，它可以用于满足后续请求而无需联系源服务器，从而提高效率。

确定新鲜度的主要机制是源服务器使用Expires头字段（第5.3节）或max-age响应指令（第5.2.2.8节）提供未来的显式过期时间。通常，源服务器会为响应分配未来的显式过期时间，相信表示在到达过期时间之前不太可能以语义上重要的方式发生变化。

如果源服务器希望强制缓存验证每个请求，它可以分配过去的显式过期时间以指示响应已经过期。符合标准的缓存通常会在将过期的缓存响应重用于后续请求之前对其进行验证（见第4.2.4节）。

由于源服务器并不总是提供显式过期时间，因此在某些情况下，缓存也可以使用启发式方法来确定过期时间（见第4.2.2节）。

确定响应是否新鲜的计算公式为:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime 在第4.2.1节中定义; current_age 在第4.2.3节中定义。

客户端可以在请求中发送max-age或min-fresh缓存指令，以约束或放宽相应响应的新鲜度计算（第5.2.1节）。

在计算新鲜度时，为避免日期解析中的常见问题:

  • 尽管所有日期格式都指定为区分大小写，但缓存接收者应该 (SHOULD) 不区分大小写地匹配日、周和时区名称。
  • 如果缓存接收者的时间内部实现的分辨率低于HTTP-date的值，则接收者必须 (MUST) 在内部将解析的Expires日期表示为等于或早于接收值的最接近时间。
  • 缓存接收者不得 (MUST NOT) 允许本地时区影响年龄或过期时间的计算或比较。
  • 缓存接收者应该 (SHOULD) 将具有GMT或UTC以外的时区缩写的日期视为无效以计算过期。

请注意，新鲜度仅适用于缓存操作; 它不能用于强制用户代理刷新其显示或重新加载资源。有关缓存和历史记录机制之间差异的说明，请参见第6节。

🇯🇵 日本語​

新鮮なレスポンス (Fresh Response) とは、その経過時間 (Age) がまだ鮮度有効期間 (Freshness Lifetime) を超えていないものである。逆に、古いレスポンス (Stale Response) とは、それを超えたものである。

レスポンスの鮮度有効期間は、オリジンサーバーによって生成されてから有効期限までの時間の長さである。明示的な有効期限 (Explicit Expiration Time) は、オリジンサーバーが、それ以降はキャッシュがさらなる検証なしに保存されたレスポンスを使用できなくなることを意図する時刻であり、一方、ヒューリスティック有効期限 (Heuristic Expiration Time) は、明示的な有効期限が利用できない場合にキャッシュによって割り当てられる。

レスポンスの経過時間は、オリジンサーバーによって生成されてから、または正常に検証されてから経過した時間である。

レスポンスがキャッシュ内で「新鮮」である場合、オリジンサーバーに接触することなく後続のリクエストを満たすために使用でき、効率を向上させる。

鮮度を決定する主なメカニズムは、オリジンサーバーがExpiresヘッダーフィールド（セクション5.3）またはmax-ageレスポンスディレクティブ（セクション5.2.2.8）を使用して、将来の明示的な有効期限を提供することである。一般に、オリジンサーバーは、有効期限に達する前に表現が意味的に重要な方法で変更される可能性が低いという信念のもとに、レスポンスに将来の明示的な有効期限を割り当てる。

オリジンサーバーがすべてのリクエストをキャッシュに検証させたい場合、レスポンスがすでに古いことを示すために、過去の明示的な有効期限を割り当てることができる。準拠するキャッシュは通常、古いキャッシュされたレスポンスを後続のリクエストに再利用する前に検証する（セクション4.2.4参照）。

オリジンサーバーが常に明示的な有効期限を提供するわけではないため、キャッシュは特定の状況下でヒューリスティックを使用して有効期限を決定することも許可されている（セクション4.2.2参照）。

レスポンスが新鮮かどうかを判断する計算は次のとおりである:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime はセクション4.2.1で定義されている; current_age はセクション4.2.3で定義されている。

クライアントは、リクエスト内でmax-ageまたはmin-freshキャッシュディレクティブを送信して、対応するレスポンスの鮮度計算を制約または緩和できる（セクション5.2.1）。

鮮度を計算する際、日付解析における一般的な問題を回避するために:

  • すべての日付形式は大文字と小文字を区別するように指定されているが、キャッシュ受信者は日、週、タイムゾーン名を大文字と小文字を区別せずに照合すべきである (SHOULD)。
  • キャッシュ受信者の時間の内部実装がHTTP-dateの値よりも解像度が低い場合、受信者は解析されたExpires日付を、受信した値以下の最も近い時間として内部的に表現しなければならない (MUST)。
  • キャッシュ受信者は、ローカルタイムゾーンが経過時間または有効期限の計算または比較に影響を与えることを許可してはならない (MUST NOT)。
  • キャッシュ受信者は、GMTまたはUTC以外のタイムゾーン略語を持つ日付を、有効期限の計算に対して無効であると見なすべきである (SHOULD)。

鮮度はキャッシュ操作にのみ適用されることに注意すること; ユーザーエージェントに表示を更新させたり、リソースを再ロードさせたりするために使用することはできない。キャッシュと履歴メカニズムの違いの説明については、セクション6を参照すること。

🇫🇷 Français​

Une réponse fraîche (Fresh Response) est une réponse dont l'âge n'a pas encore dépassé sa durée de vie de fraîcheur (Freshness Lifetime). À l'inverse, une réponse périmée (Stale Response) est une réponse qui l'a dépassée.

La durée de vie de fraîcheur d'une réponse est la durée entre sa génération par le serveur d'origine et son temps d'expiration. Un temps d'expiration explicite (Explicit Expiration Time) est le moment auquel le serveur d'origine entend qu'une réponse stockée ne peut plus être utilisée par un cache sans validation supplémentaire, tandis qu'un temps d'expiration heuristique (Heuristic Expiration Time) est attribué par un cache lorsqu'aucun temps d'expiration explicite n'est disponible.

L'âge d'une réponse (Age) est le temps qui s'est écoulé depuis qu'elle a été générée par, ou validée avec succès auprès du serveur d'origine.

Lorsqu'une réponse est « fraîche » dans le cache, elle peut être utilisée pour satisfaire des requêtes ultérieures sans contacter le serveur d'origine, améliorant ainsi l'efficacité.

Le mécanisme principal pour déterminer la fraîcheur est que le serveur d'origine fournisse un temps d'expiration explicite dans le futur, en utilisant 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 des temps d'expiration explicites futurs aux réponses en partant du principe que la représentation n'est pas susceptible de changer de manière sémantiquement significative avant que le temps d'expiration ne soit atteint.

Si un serveur d'origine souhaite forcer un cache à valider chaque requête, il peut attribuer un temps d'expiration explicite dans le passé pour indiquer que la réponse est déjà périmée. Les caches conformes valideront normalement une réponse en cache périmée avant de la réutiliser pour des requêtes ultérieures (voir Section 4.2.4).

Puisque les serveurs d'origine ne fournissent pas toujours des temps d'expiration explicites, les caches sont également autorisés à utiliser une heuristique pour déterminer un temps d'expiration dans certaines circonstances (voir Section 4.2.2).

Le calcul pour déterminer si une réponse est fraîche est :

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime est défini dans la Section 4.2.1 ; current_age est défini dans la Section 4.2.3.

Les clients peuvent envoyer les directives de cache max-age ou min-fresh dans une requête pour contraindre ou assouplir les calculs de fraîcheur pour la réponse correspondante (Section 5.2.1).

Lors du calcul de la fraîcheur, pour éviter les problèmes courants d'analyse des dates :

  • Bien que tous les formats de date soient spécifiés comme sensibles à la casse, un destinataire de cache DEVRAIT (SHOULD) faire correspondre les noms de jours, de semaines et de fuseaux horaires de manière insensible à la casse.
  • Si l'implémentation interne du temps d'un destinataire de cache a une résolution inférieure à la valeur d'une HTTP-date, le destinataire DOIT (MUST) représenter en interne une date Expires analysée comme le moment le plus proche égal ou antérieur à la valeur reçue.
  • Un destinataire de cache NE DOIT PAS (MUST NOT) permettre aux fuseaux horaires locaux d'influencer le calcul ou la comparaison d'un âge ou d'un temps d'expiration.
  • Un destinataire de cache DEVRAIT (SHOULD) considérer une date avec une abréviation de zone autre que GMT ou UTC comme invalide pour le calcul de l'expiration.

Notez que la fraîcheur s'applique uniquement au fonctionnement du cache ; elle ne peut pas être utilisée pour forcer un agent utilisateur à actualiser son affichage ou à recharger une ressource. Voir la Section 6 pour une explication de la différence entre les caches et les mécanismes d'historique.

🇩🇪 Deutsch​

Eine frische Antwort (Fresh Response) ist eine Antwort, deren Alter ihre Frische-Lebensdauer (Freshness Lifetime) noch nicht überschritten hat. Umgekehrt ist eine veraltete Antwort (Stale Response) eine Antwort, die dies getan hat.

Die Frische-Lebensdauer einer Antwort ist die Zeitdauer zwischen ihrer Erzeugung durch den Ursprungsserver und ihrer Ablaufzeit. Eine explizite Ablaufzeit (Explicit Expiration Time) ist die Zeit, zu der der Ursprungsserver beabsichtigt, dass eine gespeicherte Antwort nicht mehr von einem Cache ohne weitere Validierung verwendet werden kann, während eine heuristische Ablaufzeit (Heuristic Expiration Time) von einem Cache zugewiesen wird, wenn keine explizite Ablaufzeit verfügbar ist.

Das Alter einer Antwort (Age) ist die Zeit, die seit ihrer Erzeugung durch oder erfolgreichen Validierung beim Ursprungsserver vergangen ist.

Wenn eine Antwort im Cache „frisch" ist, kann sie verwendet werden, um nachfolgende Anfragen zu erfüllen, ohne den Ursprungsserver zu kontaktieren, wodurch die Effizienz verbessert wird.

Der primäre Mechanismus zur Bestimmung der Frische besteht darin, dass der Ursprungsserver eine explizite Ablaufzeit in der Zukunft bereitstellt, entweder über das Expires-Header-Feld (Abschnitt 5.3) oder die max-age-Antwortdirektive (Abschnitt 5.2.2.8). Im Allgemeinen weisen Ursprungsserver Antworten zukünftige explizite Ablaufzeiten zu, in der Annahme, dass die Darstellung sich vor Erreichen der Ablaufzeit wahrscheinlich nicht in semantisch signifikanter Weise ändern wird.

Wenn ein Ursprungsserver einen Cache zwingen möchte, jede Anfrage zu validieren, kann er eine explizite Ablaufzeit in der Vergangenheit zuweisen, um anzuzeigen, dass die Antwort bereits veraltet ist. Konforme Caches validieren normalerweise eine veraltete gecachte Antwort, bevor sie sie für nachfolgende Anfragen wiederverwenden (siehe Abschnitt 4.2.4).

Da Ursprungsserver nicht immer explizite Ablaufzeiten bereitstellen, dürfen Caches unter bestimmten Umständen auch eine Heuristik verwenden, um eine Ablaufzeit zu bestimmen (siehe Abschnitt 4.2.2).

Die Berechnung zur Bestimmung, ob eine Antwort frisch ist, lautet:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime ist in Abschnitt 4.2.1 definiert; current_age ist in Abschnitt 4.2.3 definiert.

Clients können die max-age- oder min-fresh-Cache-Direktiven in einer Anfrage senden, um Frischeberechnungen für die entsprechende Antwort einzuschränken oder zu lockern (Abschnitt 5.2.1).

Beim Berechnen der Frische, um häufige Probleme beim Parsen von Daten zu vermeiden:

  • Obwohl alle Datumsformate als groß-/kleinschreibungsempfindlich spezifiziert sind, SOLLTE (SHOULD) ein Cache-Empfänger Tag-, Wochen- und Zeitzonennamen groß-/kleinschreibungsunabhängig abgleichen.
  • Wenn die interne Zeitimplementierung eines Cache-Empfängers eine geringere Auflösung als der Wert eines HTTP-date hat, MUSS (MUST) der Empfänger ein gepartes Expires-Datum intern als die nächstgelegene Zeit darstellen, die gleich oder früher als der empfangene Wert ist.
  • Ein Cache-Empfänger DARF NICHT (MUST NOT) zulassen, dass lokale Zeitzonen die Berechnung oder den Vergleich eines Alters oder einer Ablaufzeit beeinflussen.
  • Ein Cache-Empfänger SOLLTE (SHOULD) ein Datum mit einer Zonenabkürzung außer GMT oder UTC als ungültig für die Berechnung der Ablaufzeit betrachten.

Beachten Sie, dass Frische nur für den Cache-Betrieb gilt; sie kann nicht verwendet werden, um einen User Agent zu zwingen, seine Anzeige zu aktualisieren oder eine Ressource neu zu laden. Siehe Abschnitt 6 für eine Erklärung des Unterschieds zwischen Caches und Verlaufsmechanismen.

🇮🇹 Italiano​

Una risposta fresca (Fresh Response) è una risposta la cui età non ha ancora superato la sua durata di freschezza (Freshness Lifetime). Al contrario, una risposta obsoleta (Stale Response) è una risposta che l'ha superata.

La durata di freschezza di una risposta è il periodo di tempo tra la sua generazione da parte del server di origine e il suo tempo di scadenza. Un tempo di scadenza esplicito (Explicit Expiration Time) è il momento in cui il server di origine intende che una risposta memorizzata non possa più essere utilizzata da una cache senza ulteriore validazione, mentre un tempo di scadenza euristico (Heuristic Expiration Time) viene assegnato da una cache quando non è disponibile un tempo di scadenza esplicito.

L'età di una risposta (Age) è il tempo trascorso da quando è stata generata da, o validata con successo con, il server di origine.

Quando una risposta è "fresca" nella cache, può essere utilizzata per soddisfare richieste successive senza contattare il server di origine, migliorando così l'efficienza.

Il meccanismo principale per determinare la freschezza è che il server di origine fornisca un tempo di scadenza esplicito nel futuro, utilizzando il campo di intestazione Expires (Sezione 5.3) o la direttiva di risposta max-age (Sezione 5.2.2.8). In generale, i server di origine assegneranno tempi di scadenza espliciti futuri alle risposte nella convinzione che la rappresentazione non sia suscettibile di cambiare in modo semanticamente significativo prima che venga raggiunto il tempo di scadenza.

Se un server di origine desidera forzare una cache a validare ogni richiesta, può assegnare un tempo di scadenza esplicito nel passato per indicare che la risposta è già obsoleta. Le cache conformi normalmente valideranno una risposta in cache obsoleta prima di riutilizzarla per richieste successive (vedere Sezione 4.2.4).

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, le cache sono anche autorizzate a utilizzare un'euristica per determinare un tempo di scadenza in determinate circostanze (vedere Sezione 4.2.2).

Il calcolo per determinare se una risposta è fresca è:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime è definito nella Sezione 4.2.1; current_age è definito nella Sezione 4.2.3.

I client possono inviare le direttive di cache max-age o min-fresh in una richiesta per vincolare o rilassare i calcoli di freschezza per la risposta corrispondente (Sezione 5.2.1).

Quando si calcola la freschezza, per evitare problemi comuni nell'analisi delle date:

  • Sebbene tutti i formati di data siano specificati come sensibili alle maiuscole/minuscole, un destinatario di cache DOVREBBE (SHOULD) abbinare i nomi di giorni, settimane e fusi orari senza distinzione tra maiuscole e minuscole.
  • Se l'implementazione interna del tempo di un destinatario di cache ha una risoluzione inferiore al valore di una HTTP-date, il destinatario DEVE (MUST) rappresentare internamente una data Expires analizzata come il momento più vicino uguale o precedente al valore ricevuto.
  • Un destinatario di cache NON DEVE (MUST NOT) consentire ai fusi orari locali di influenzare il calcolo o il confronto di un'età o di un tempo di scadenza.
  • Un destinatario di cache DOVREBBE (SHOULD) considerare una data con un'abbreviazione di zona diversa da GMT o UTC come non valida per il calcolo della scadenza.

Si noti che la freschezza si applica solo al funzionamento della cache; non può essere utilizzata per forzare un user agent ad aggiornare la sua visualizzazione o ricaricare una risorsa. Vedere la Sezione 6 per una spiegazione della differenza tra cache e meccanismi di cronologia.

📝 翻译说明 (Translation Notes)

  • 核心概念术语:
    • Fresh/Stale (新鲜/过期, 新鮮/古い, fraîche/périmée, frisch/veraltet, fresca/obsoleta)
    • Freshness Lifetime (新鲜度生命周期, 鮮度有効期間, durée de vie de fraîcheur, Frische-Lebensdauer, durata di freschezza)
    • Explicit/Heuristic Expiration Time (显式/启发式过期时间)
  • RFC 2119关键词: MUST, SHOULD, MUST NOT等保留英文，符合国际标准
  • 算法公式: response_is_fresh = (freshness_lifetime > current_age) 所有语言版本保持一致
  • 法律级严谨性: 特别注意日期解析规则，所有语言版本都保持了RFC要求的精确性
Ultimo aggiornamento il