5.2.3. Cache Control Extensions (缓存控制扩展)
🇬🇧 English
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional value. A cache MUST ignore unrecognized cache directives.
Informational extensions (those that do not require a change in cache behavior) can 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 that 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 Cache-Control directives can be made without breaking deployed caches.
For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive: in addition to private caches, any cache that is shared only by members of the named community is allowed to cache the response. An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including
Cache-Control: private, community="UCI"
A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache that does not recognize the community cache-extension would ignore it and adhere to the private directive.
🇨🇳 中文
Cache-Control头字段可以通过使用一个或多个缓存扩展令牌来扩展，每个令牌都有一个可选值。缓存必须 (MUST) 忽略无法识别的缓存指令。
信息性扩展（不需要更改缓存行为的扩展）可以在不更改其他指令语义的情况下添加。
行为扩展旨在通过充当现有缓存指令基础的修饰符来工作。新指令和标准指令都被提供，因此不理解新指令的应用程序将默认使用标准指令指定的行为，而理解新指令的应用程序将识别它正在修改与标准指令相关的要求。通过这种方式，可以在不破坏已部署缓存的情况下对Cache-Control指令进行扩展。
例如，考虑一个假设的新响应指令，称为"community"，它充当private指令的修饰符: 除了私有缓存之外，仅由命名社区的成员共享的任何缓存都被允许缓存响应。希望允许UCI社区在其共享缓存中使用原本私有的响应的源服务器可以通过包含以下内容来实现
Cache-Control: private, community="UCI"
识别此类community缓存扩展的缓存可以根据该扩展扩大其行为。不识别community缓存扩展的缓存将忽略它并遵守private指令。
🇯🇵 日本語
Cache-Controlヘッダーフィールドは、それぞれオプションの値を持つ1つ以上のキャッシュ拡張トークンを使用して拡張できる。キャッシュは認識できないキャッシュディレクティブを無視しなければならない (MUST)。
情報拡張（キャッシュ動作の変更を必要としない拡張）は、他のディレクティブのセマンティクスを変更せずに追加できる。
動作拡張は、既存のキャッシュディレクティブの基盤への修飾子として機能することで動作するように設計されている。新しいディレクティブと標準ディレクティブの両方が提供されるため、新しいディレクティブを理解しないアプリケーションは標準ディレクティブで指定された動作にデフォルト設定され、新しいディレクティブを理解するアプリケーションは、それが標準ディレクティブに関連する要件を変更していることを認識する。このように、デプロイされたキャッシュを破壊することなくCache-Controlディレクティブへの拡張を行うことができる。
例えば、privateディレクティブへの修飾子として機能する"community"と呼ばれる仮想の新しいレスポンスディレクティブを考える: プライベートキャッシュに加えて、名前付きコミュニティのメンバーのみによって共有される任意のキャッシュがレスポンスをキャッシュすることを許可される。UCIコミュニティが本来プライベートなレスポンスを共有キャッシュで使用できるようにしたいオリジンサーバーは、次を含めることでそれを実行できる
Cache-Control: private, community="UCI"
このようなcommunityキャッシュ拡張を認識するキャッシュは、その拡張に従って動作を拡大できる。communityキャッシュ拡張を認識しないキャッシュは、それを無視してprivateディレクティブに従う。
🇫🇷 Français
Le champ d'en-tête Cache-Control peut être étendu par l'utilisation d'un ou plusieurs jetons d'extension de cache, chacun avec une valeur optionnelle. Un cache DOIT (MUST) ignorer les directives de cache non reconnues.
Les extensions informationnelles (celles qui ne nécessitent pas de changement dans le comportement du cache) peuvent être ajoutées sans changer la sémantique des autres directives.
Les extensions comportementales sont conçues pour fonctionner en agissant comme des modificateurs de la base existante de directives de cache. La nouvelle directive et la directive standard sont toutes deux fournies, de sorte que les applications qui ne comprennent pas la nouvelle directive utiliseront par défaut le comportement spécifié par la directive standard, et celles qui comprennent la nouvelle directive la reconnaîtront comme modifiant les exigences associées à la directive standard. De cette manière, les extensions aux directives Cache-Control peuvent être faites sans casser les caches déployés.
Par exemple, considérons une nouvelle directive de réponse hypothétique appelée "community" qui agit comme un modificateur de la directive private : en plus des caches privés, tout cache qui est partagé uniquement par les membres de la communauté nommée est autorisé à mettre en cache la réponse. Un serveur d'origine souhaitant permettre à la communauté UCI d'utiliser une réponse autrement privée dans son ou ses caches partagés pourrait le faire en incluant
Cache-Control: private, community="UCI"
Un cache qui reconnaît une telle extension de cache community pourrait élargir son comportement conformément à cette extension. Un cache qui ne reconnaît pas l'extension de cache community l'ignorerait et adhérerait à la directive private.
🇩🇪 Deutsch
Das Cache-Control-Header-Feld kann durch die Verwendung eines oder mehrerer Cache-Erweiterungs-Tokens erweitert werden, jedes mit einem optionalen Wert. Ein Cache MUSS (MUST) nicht erkannte Cache-Direktiven ignorieren.
Informationserweiterungen (solche, die keine Änderung des Cache-Verhaltens erfordern) können hinzugefügt werden, ohne die Semantik anderer Direktiven zu ändern.
Verhaltenserweiterungen sind so konzipiert, dass sie funktionieren, indem sie als Modifikatoren zur bestehenden Basis von Cache-Direktiven fungieren. Sowohl die neue Direktive als auch die Standarddirektive werden bereitgestellt, sodass Anwendungen, die die neue Direktive nicht verstehen, standardmäßig auf das durch die Standarddirektive angegebene Verhalten zurückgreifen, und diejenigen, die die neue Direktive verstehen, sie als Modifikation der mit der Standarddirektive verbundenen Anforderungen erkennen. Auf diese Weise können Erweiterungen der Cache-Control-Direktiven vorgenommen werden, ohne bereitgestellte Caches zu zerstören.
Betrachten Sie beispielsweise eine hypothetische neue Antwortdirektive namens "community", die als Modifikator der private-Direktive fungiert: Zusätzlich zu privaten Caches darf jeder Cache, der nur von Mitgliedern der benannten Community gemeinsam genutzt wird, die Antwort zwischenspeichern. Ein Ursprungsserver, der der UCI-Community erlauben möchte, eine ansonsten private Antwort in ihren gemeinsam genutzten Caches zu verwenden, könnte dies tun, indem er Folgendes einschließt
Cache-Control: private, community="UCI"
Ein Cache, der eine solche community-Cache-Erweiterung erkennt, könnte sein Verhalten gemäß dieser Erweiterung erweitern. Ein Cache, der die community-Cache-Erweiterung nicht erkennt, würde sie ignorieren und sich an die private-Direktive halten.
🇮🇹 Italiano
Il campo di intestazione Cache-Control può essere esteso attraverso l'uso di uno o più token di estensione della cache, ciascuno con un valore opzionale. Una cache DEVE (MUST) ignorare le direttive di cache non riconosciute.
Le estensioni informative (quelle che non richiedono un cambiamento nel comportamento della cache) possono essere aggiunte senza cambiare la semantica delle altre direttive.
Le estensioni comportamentali sono progettate per funzionare agendo come modificatori della base esistente di direttive di cache. Vengono fornite sia la nuova direttiva che la direttiva standard, in modo che le applicazioni che non comprendono la nuova direttiva utilizzeranno per impostazione predefinita il comportamento specificato dalla direttiva standard, e quelle che comprendono la nuova direttiva la riconosceranno come modifica dei requisiti associati alla direttiva standard. In questo modo, le estensioni alle direttive Cache-Control possono essere effettuate senza interrompere le cache distribuite.
Ad esempio, si consideri una nuova direttiva di risposta ipotetica chiamata "community" che agisce come modificatore della direttiva private: oltre alle cache private, qualsiasi cache condivisa solo dai membri della comunità nominata è autorizzata a memorizzare in cache la risposta. Un server di origine che desidera consentire alla comunità UCI di utilizzare una risposta altrimenti privata nella propria cache condivisa potrebbe farlo includendo
Cache-Control: private, community="UCI"
Una cache che riconosce tale estensione di cache community potrebbe ampliare il suo comportamento in conformità con tale estensione. Una cache che non riconosce l'estensione di cache community la ignorerebbe e aderirebbe alla direttiva private.
5.3. Expires (过期时间)
🇬🇧 English
The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
The Expires field value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231].
Expires = HTTP-date
For example:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
If a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field.
An origin server without a clock MUST NOT generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated with the resource by some other system or person with a reliable clock.
Historically, HTTP required the Expires field value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values (e.g., a future date beyond the year 9999) are discouraged because they can cause problems with timestamp parsing and arithmetic overflow.
🇨🇳 中文
"Expires"头字段给出了响应被视为过期的日期/时间。有关新鲜度模型的进一步讨论，请参见第4.2节。
Expires字段的存在并不意味着原始资源将在该时间之前、当时或之后更改或停止存在。
Expires字段值是HTTP日期时间戳，如 [RFC7231] 的第7.1.1.1节所定义。
Expires = HTTP-date
例如:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
缓存接收方必须 (MUST) 将无效的日期格式（特别是值"0"）解释为表示过去的时间（即"已经过期"）。
如果响应包含带有max-age指令的Cache-Control字段（第5.2.2.8节），则接收方必须 (MUST) 忽略Expires字段。同样，如果响应包含s-maxage指令（第5.2.2.9节），则共享缓存接收方必须 (MUST) 忽略Expires字段。在这两种情况下，Expires中的值仅用于尚未实现Cache-Control字段的接收方。
没有时钟的源服务器不得 (MUST NOT) 生成Expires字段，除非其值表示过去的固定时间（始终过期）或其值已由具有可靠时钟的某个其他系统或人员与资源关联。
从历史上看，HTTP要求Expires字段值不超过未来一年。虽然不再禁止更长的新鲜度生命周期，但不鼓励使用极大的值（例如，超过9999年的未来日期），因为它们可能导致时间戳解析和算术溢出问题。
🇯🇵 日本語
"Expires"ヘッダーフィールドは、レスポンスが古いと見なされる日付/時刻を示す。鮮度モデルのさらなる議論については、セクション4.2を参照。
Expiresフィールドの存在は、元のリソースがその時刻の前、その時刻、またはその時刻の後に変更されるか存在しなくなることを意味しない。
Expiresフィールド値は、[RFC7231] のセクション7.1.1.1で定義されているHTTP日付タイムスタンプである。
Expires = HTTP-date
例えば:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
キャッシュ受信者は、無効な日付形式、特に値"0"を、過去の時刻（つまり、「すでに期限切れ」）を表すものとして解釈しなければならない (MUST)。
レスポンスにmax-ageディレクティブ（セクション5.2.2.8）を含むCache-Controlフィールドが含まれている場合、受信者はExpiresフィールドを無視しなければならない (MUST)。同様に、レスポンスにs-maxageディレクティブ（セクション5.2.2.9）が含まれている場合、共有キャッシュ受信者はExpiresフィールドを無視しなければならない (MUST)。これらの両方の場合、Expires内の値は、Cache-Controlフィールドをまだ実装していない受信者のみを対象としている。
時計を持たないオリジンサーバーは、その値が過去の固定時刻（常に期限切れ）を表すか、その値が信頼できる時計を持つ他のシステムまたは人物によってリソースに関連付けられていない限り、Expiresフィールドを生成してはならない (MUST NOT)。
歴史的に、HTTPはExpiresフィールド値が未来1年以内であることを要求していた。より長い鮮度有効期間はもはや禁止されていないが、極端に大きな値（例えば、9999年を超える未来の日付）は、タイムスタンプの解析と算術オーバーフローの問題を引き起こす可能性があるため、推奨されない。
🇫🇷 Français
Le champ d'en-tête "Expires" donne la date/heure après laquelle la réponse est considérée comme périmée. Voir Section 4.2 pour une discussion plus approfondie du modèle de fraîcheur.
La présence d'un champ Expires n'implique pas que la ressource d'origine changera ou cessera d'exister à, avant ou après ce moment.
La valeur du champ Expires est un horodatage HTTP-date, tel que défini dans la Section 7.1.1.1 de [RFC7231].
Expires = HTTP-date
Par exemple :
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Un destinataire de cache DOIT (MUST) interpréter les formats de date invalides, en particulier la valeur "0", comme représentant un moment dans le passé (c'est-à-dire, "déjà expiré").
Si une réponse inclut un champ Cache-Control avec la directive max-age (Section 5.2.2.8), un destinataire DOIT (MUST) ignorer le champ Expires. De même, si une réponse inclut la directive s-maxage (Section 5.2.2.9), un destinataire de cache partagé DOIT (MUST) ignorer le champ Expires. Dans ces deux cas, la valeur dans Expires est uniquement destinée aux destinataires qui n'ont pas encore implémenté le champ Cache-Control.
Un serveur d'origine sans horloge NE DOIT PAS (MUST NOT) générer un champ Expires à moins que sa valeur ne représente un moment fixe dans le passé (toujours expiré) ou que sa valeur n'ait été associée à la ressource par un autre système ou une personne disposant d'une horloge fiable.
Historiquement, HTTP exigeait que la valeur du champ Expires ne soit pas supérieure à un an dans le futur. Bien que des durées de fraîcheur plus longues ne soient plus interdites, les valeurs extrêmement grandes (par exemple, une date future au-delà de l'année 9999) sont découragées car elles peuvent causer des problèmes avec l'analyse des horodatages et le débordement arithmétique.
🇩🇪 Deutsch
Das "Expires"-Header-Feld gibt das Datum/die Uhrzeit an, nach der die Antwort als veraltet gilt. Siehe Abschnitt 4.2 für weitere Diskussionen zum Frische-Modell.
Das Vorhandensein eines Expires-Felds impliziert nicht, dass die ursprüngliche Ressource zu, vor oder nach dieser Zeit geändert wird oder aufhört zu existieren.
Der Expires-Feldwert ist ein HTTP-Datums-Zeitstempel, wie in Abschnitt 7.1.1.1 von [RFC7231] definiert.
Expires = HTTP-date
Zum Beispiel:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Ein Cache-Empfänger MUSS (MUST) ungültige Datumsformate, insbesondere den Wert "0", als Zeitpunkt in der Vergangenheit (d. h. "bereits abgelaufen") interpretieren.
Wenn eine Antwort ein Cache-Control-Feld mit der max-age-Direktive enthält (Abschnitt 5.2.2.8), MUSS (MUST) ein Empfänger das Expires-Feld ignorieren. Ebenso, wenn eine Antwort die s-maxage-Direktive enthält (Abschnitt 5.2.2.9), MUSS (MUST) ein gemeinsam genutzter Cache-Empfänger das Expires-Feld ignorieren. In beiden Fällen ist der Wert in Expires nur für Empfänger gedacht, die das Cache-Control-Feld noch nicht implementiert haben.
Ein Ursprungsserver ohne Uhr DARF NICHT (MUST NOT) ein Expires-Feld generieren, es sei denn, sein Wert stellt eine feste Zeit in der Vergangenheit dar (immer abgelaufen) oder sein Wert wurde von einem anderen System oder einer Person mit einer zuverlässigen Uhr mit der Ressource verknüpft.
Historisch gesehen verlangte HTTP, dass der Expires-Feldwert nicht mehr als ein Jahr in der Zukunft liegt. Während längere Frischelebensdauern nicht mehr verboten sind, werden extrem große Werte (z. B. ein zukünftiges Datum jenseits des Jahres 9999) nicht empfohlen, da sie Probleme mit Zeitstempel-Parsing und arithmetischem Überlauf verursachen können.
🇮🇹 Italiano
Il campo di intestazione "Expires" fornisce la data/ora dopo la quale la risposta è considerata obsoleta. Vedere Sezione 4.2 per ulteriori discussioni sul modello di freschezza.
La presenza di un campo Expires non implica che la risorsa originale cambierà o cesserà di esistere a, prima o dopo quel momento.
Il valore del campo Expires è un timestamp HTTP-date, come definito nella Sezione 7.1.1.1 di [RFC7231].
Expires = HTTP-date
Ad esempio:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Un destinatario di cache DEVE (MUST) interpretare i formati di data non validi, in particolare il valore "0", come rappresentanti un momento nel passato (cioè, "già scaduto").
Se una risposta include un campo Cache-Control con la direttiva max-age (Sezione 5.2.2.8), un destinatario DEVE (MUST) ignorare il campo Expires. Allo stesso modo, se una risposta include la direttiva s-maxage (Sezione 5.2.2.9), un destinatario di cache condivisa DEVE (MUST) ignorare il campo Expires. In entrambi questi casi, il valore in Expires è destinato solo ai destinatari che non hanno ancora implementato il campo Cache-Control.
Un server di origine senza orologio NON DEVE (MUST NOT) generare un campo Expires a meno che il suo valore non rappresenti un momento fisso nel passato (sempre scaduto) o il suo valore non sia stato associato alla risorsa da qualche altro sistema o persona con un orologio affidabile.
Storicamente, HTTP richiedeva che il valore del campo Expires non fosse superiore a un anno nel futuro. Sebbene durate di freschezza più lunghe non siano più vietate, valori estremamente grandi (ad esempio, una data futura oltre l'anno 9999) sono sconsigliati perché possono causare problemi con l'analisi dei timestamp e l'overflow aritmetico.
5.4. Pragma (编译指示)
🇬🇧 English
The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.
In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates Pragma for anything other than backwards compatibility with HTTP/1.0 deployments.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
When the Cache-Control header field is not present in a request, caches MUST consider the request's Pragma header field to determine whether there is a "no-cache" directive.
Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them. Senders SHOULD NOT generate Pragma in an HTTP/1.1 message that includes Cache-Control.
🇨🇳 中文
"Pragma"头字段允许与HTTP/1.0缓存向后兼容，以便客户端可以指定它们将理解的"no-cache"请求（因为Cache-Control直到HTTP/1.1才定义）。当请求中还存在并理解Cache-Control头字段时，Pragma将被忽略。
在HTTP/1.0中，Pragma被定义为用于接收方实现指定指令的可扩展字段。本规范不推荐将Pragma用于除与HTTP/1.0部署向后兼容以外的任何用途。
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
当请求中不存在Cache-Control头字段时，缓存必须 (MUST) 考虑请求的Pragma头字段以确定是否存在"no-cache"指令。
注意: 因为响应中"Pragma: no-cache"的含义未指定，所以它不能为响应中的"Cache-Control: no-cache"提供可靠的替代。发送方不应该 (SHOULD NOT) 在包含Cache-Control的HTTP/1.1消息中生成Pragma。
🇯🇵 日本語
"Pragma"ヘッダーフィールドは、HTTP/1.0キャッシュとの下位互換性を可能にし、クライアントが理解する"no-cache"リクエストを指定できるようにする（Cache-ControlはHTTP/1.1まで定義されなかったため）。リクエスト内にCache-Controlヘッダーフィールドも存在し理解される場合、Pragmaは無視される。
HTTP/1.0では、Pragmaは受信者向けの実装固有ディレクティブのための拡張可能なフィールドとして定義されていた。この仕様では、HTTP/1.0デプロイとの下位互換性以外の目的でのPragmaの使用を非推奨とする。
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
リクエスト内にCache-Controlヘッダーフィールドが存在しない場合、キャッシュはリクエストのPragmaヘッダーフィールドを考慮して"no-cache"ディレクティブが存在するかどうかを判断しなければならない (MUST)。
注: レスポンス内の"Pragma: no-cache"の意味が指定されていないため、それらの中で"Cache-Control: no-cache"の信頼できる代替を提供しない。送信者は、Cache-Controlを含むHTTP/1.1メッセージでPragmaを生成すべきではない (SHOULD NOT)。
🇫🇷 Français
Le champ d'en-tête "Pragma" permet la rétrocompatibilité avec les caches HTTP/1.0, afin que les clients puissent spécifier une requête "no-cache" qu'ils comprendront (car Cache-Control n'a été défini qu'avec HTTP/1.1). Lorsque le champ d'en-tête Cache-Control est également présent et compris dans une requête, Pragma est ignoré.
Dans HTTP/1.0, Pragma était défini comme un champ extensible pour les directives spécifiques à l'implémentation pour les destinataires. Cette spécification déconseille l'utilisation de Pragma pour autre chose que la rétrocompatibilité avec les déploiements HTTP/1.0.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
Lorsque le champ d'en-tête Cache-Control n'est pas présent dans une requête, les caches DOIVENT (MUST) considérer le champ d'en-tête Pragma de la requête pour déterminer s'il y a une directive "no-cache".
Remarque : Étant donné que la signification de "Pragma : no-cache" dans les réponses n'est pas spécifiée, elle ne fournit pas un remplacement fiable pour "Cache-Control : no-cache" dans celles-ci. Les émetteurs NE DEVRAIENT PAS (SHOULD NOT) générer Pragma dans un message HTTP/1.1 qui inclut Cache-Control.
🇩🇪 Deutsch
Das "Pragma"-Header-Feld ermöglicht Rückwärtskompatibilität mit HTTP/1.0-Caches, sodass Clients eine "no-cache"-Anfrage angeben können, die sie verstehen (da Cache-Control erst ab HTTP/1.1 definiert wurde). Wenn das Cache-Control-Header-Feld auch in einer Anfrage vorhanden und verstanden wird, wird Pragma ignoriert.
In HTTP/1.0 wurde Pragma als erweiterbares Feld für implementierungsspezifische Direktiven für Empfänger definiert. Diese Spezifikation missbilligt Pragma für alles andere als Rückwärtskompatibilität mit HTTP/1.0-Bereitstellungen.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
Wenn das Cache-Control-Header-Feld in einer Anfrage nicht vorhanden ist, MÜSSEN (MUST) Caches das Pragma-Header-Feld der Anfrage berücksichtigen, um festzustellen, ob eine "no-cache"-Direktive vorhanden ist.
Hinweis: Da die Bedeutung von "Pragma: no-cache" in Antworten nicht spezifiziert ist, bietet es keinen zuverlässigen Ersatz für "Cache-Control: no-cache" in diesen. Absender SOLLTEN NICHT (SHOULD NOT) Pragma in einer HTTP/1.1-Nachricht generieren, die Cache-Control enthält.
🇮🇹 Italiano
Il campo di intestazione "Pragma" consente la retrocompatibilità con le cache HTTP/1.0, in modo che i client possano specificare una richiesta "no-cache" che comprenderanno (poiché Cache-Control non è stato definito fino a HTTP/1.1). Quando il campo di intestazione Cache-Control è anche presente e compreso in una richiesta, Pragma viene ignorato.
In HTTP/1.0, Pragma era definito come un campo estensibile per direttive specifiche dell'implementazione per i destinatari. Questa specifica sconsiglia l'uso di Pragma per qualsiasi cosa diversa dalla retrocompatibilità con le distribuzioni HTTP/1.0.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
Quando il campo di intestazione Cache-Control non è presente in una richiesta, le cache DEVONO (MUST) considerare il campo di intestazione Pragma della richiesta per determinare se è presente una direttiva "no-cache".
Nota: Poiché il significato di "Pragma: no-cache" nelle risposte non è specificato, non fornisce una sostituzione affidabile per "Cache-Control: no-cache" in esse. I mittenti NON DOVREBBERO (SHOULD NOT) generare Pragma in un messaggio HTTP/1.1 che include Cache-Control.
📝 翻译说明 (Translation Notes)
- 5.2.3 扩展机制: community示例展示了优雅的向后兼容扩展模式，所有语言版本都准确传达了修饰符模式
- 5.3 Expires:
- 与max-age/s-maxage的优先级关系在所有语言版本中得到了明确说明
- "0"作为无效日期的特殊处理在所有语言中准确翻译
- Y9999年的极限值警告在所有语言版本中得到了保留
- 5.4 Pragma:
- HTTP/1.0向后兼容性的历史遗留特性在所有语言中得到了清晰说明
- 已被废弃(deprecated)的状态在所有语言版本中得到了准确传达
- 响应中Pragma不可靠的警告在所有语言中都得到了强调