1. Introduction (简介)
🇬🇧 English
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.
An HTTP cache is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
A shared cache is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A private cache, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.
The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in Section 4.2, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (Section 4.3) or if the origin is unavailable (Section 4.2.4).
🇨🇳 中文
HTTP通常用于分布式信息系统，通过使用响应缓存可以提高性能。本文档定义了与缓存和重用响应消息相关的HTTP/1.1的各个方面。
HTTP缓存 (HTTP Cache) 是响应消息的本地存储以及控制其中消息的存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可以 (MAY) 使用缓存，但充当隧道的服务器不能使用缓存。
共享缓存 (Shared Cache) 是存储响应以供多个用户重用的缓存; 共享缓存通常（但并非总是）作为中介的一部分部署。相比之下，私有缓存 (Private Cache) 专用于单个用户; 它们通常作为用户代理的组件部署。
HTTP/1.1中缓存的目标是通过重用先前的响应消息来满足当前请求，从而显著提高性能。如第4.2节所定义，如果响应可以在不进行"验证" (Validation)（与源服务器检查缓存的响应对于此请求是否仍然有效）的情况下重用，则存储的响应被认为是"新鲜的" (Fresh)。因此，新鲜的响应每次重用时都可以减少延迟和网络开销。当缓存的响应不新鲜时，如果可以通过验证（第4.3节）更新它或者源服务器不可用（第4.2.4节），它仍然可能是可重用的。
🇯🇵 日本語
HTTPは通常、分散情報システムで使用され、レスポンスキャッシュの使用によりパフォーマンスを向上させることができる。本文書は、キャッシュとレスポンスメッセージの再利用に関連するHTTP/1.1の側面を定義する。
HTTPキャッシュ (HTTP Cache) は、レスポンスメッセージのローカルストアであり、その中のメッセージの保存、取得、削除を制御するサブシステムである。キャッシュは、将来の同等のリクエストに対するレスポンス時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを保存する。クライアントまたはサーバーはキャッシュを使用してもよい (MAY) が、トンネルとして機能するサーバーはキャッシュを使用できない。
共有キャッシュ (Shared Cache) は、複数のユーザーによって再利用されるレスポンスを保存するキャッシュである; 共有キャッシュは通常（常にではないが）中継者の一部として展開される。対照的に、プライベートキャッシュ (Private Cache) は単一のユーザー専用である; 多くの場合、ユーザーエージェントのコンポーネントとして展開される。
HTTP/1.1におけるキャッシュの目標は、以前のレスポンスメッセージを再利用して現在のリクエストを満たすことにより、パフォーマンスを大幅に向上させることである。第4.2節で定義されているように、レスポンスが「検証」(Validation)（キャッシュされたレスポンスがこのリクエストに対して依然として有効であるかどうかをオリジンサーバーで確認すること）なしで再利用できる場合、保存されたレスポンスは「新鮮」(Fresh) であると見なされる。したがって、新鮮なレスポンスは、再利用されるたびにレイテンシとネットワークオーバーヘッドの両方を削減できる。キャッシュされたレスポンスが新鮮でない場合でも、検証によって更新できる場合（第4.3節）、またはオリジンが利用できない場合（第4.2.4節）は、再利用可能である可能性がある。
🇫🇷 Français
HTTP est généralement utilisé pour les systèmes d'information distribués, où les performances peuvent être améliorées par l'utilisation de caches de réponse. Ce document définit les aspects de HTTP/1.1 liés à la mise en cache et à la réutilisation des messages de réponse.
Un cache HTTP (HTTP Cache) est un stockage local de messages de réponse et le sous-système qui contrôle le stockage, la récupération et la suppression des messages qu'il contient. Un cache stocke les réponses pouvant être mises en cache afin de réduire le temps de réponse et la consommation de bande passante réseau pour les futures requêtes équivalentes. Tout client ou serveur PEUT (MAY) utiliser un cache, bien qu'un cache ne puisse pas être utilisé par un serveur agissant comme un tunnel.
Un cache partagé (Shared Cache) est un cache qui stocke des réponses destinées à être réutilisées par plusieurs utilisateurs ; les caches partagés sont généralement (mais pas toujours) déployés dans le cadre d'un intermédiaire. Un cache privé (Private Cache), en revanche, est dédié à un seul utilisateur ; ils sont souvent déployés comme composant d'un agent utilisateur.
L'objectif de la mise en cache dans HTTP/1.1 est d'améliorer considérablement les performances en réutilisant un message de réponse antérieur pour satisfaire une requête actuelle. Une réponse stockée est considérée comme « fraîche » (Fresh), comme défini dans la Section 4.2, si la réponse peut être réutilisée sans « validation » (Validation) (vérification avec le serveur d'origine pour voir si la réponse en cache reste valide pour cette requête). Une réponse fraîche peut donc réduire à la fois la latence et la surcharge réseau chaque fois qu'elle est réutilisée. Lorsqu'une réponse en cache n'est pas fraîche, elle peut encore être réutilisable si elle peut être actualisée par validation (Section 4.3) ou si l'origine n'est pas disponible (Section 4.2.4).
🇩🇪 Deutsch
HTTP wird typischerweise für verteilte Informationssysteme verwendet, bei denen die Leistung durch die Verwendung von Response-Caches verbessert werden kann. Dieses Dokument definiert Aspekte von HTTP/1.1 im Zusammenhang mit dem Caching und der Wiederverwendung von Response-Nachrichten.
Ein HTTP-Cache ist ein lokaler Speicher für Response-Nachrichten und das Subsystem, das die Speicherung, den Abruf und die Löschung von Nachrichten darin steuert. Ein Cache speichert cachefähige Antworten, um die Antwortzeit und den Netzwerkbandbreitenverbrauch bei zukünftigen, gleichwertigen Anfragen zu reduzieren. Jeder Client oder Server DARF (MAY) einen Cache verwenden, obwohl ein Cache nicht von einem Server verwendet werden kann, der als Tunnel fungiert.
Ein gemeinsamer Cache (Shared Cache) ist ein Cache, der Antworten speichert, die von mehr als einem Benutzer wiederverwendet werden sollen; gemeinsame Caches werden normalerweise (aber nicht immer) als Teil eines Vermittlers bereitgestellt. Ein privater Cache (Private Cache) hingegen ist einem einzelnen Benutzer gewidmet; sie werden häufig als Komponente eines User Agents bereitgestellt.
Das Ziel des Cachings in HTTP/1.1 besteht darin, die Leistung erheblich zu verbessern, indem eine frühere Response-Nachricht wiederverwendet wird, um eine aktuelle Anfrage zu erfüllen. Eine gespeicherte Antwort wird als „frisch" (Fresh) betrachtet, wie in Abschnitt 4.2 definiert, wenn die Antwort ohne „Validierung" (Validation) (Überprüfung beim Ursprungsserver, ob die gecachte Antwort für diese Anfrage noch gültig ist) wiederverwendet werden kann. Eine frische Antwort kann daher bei jeder Wiederverwendung sowohl die Latenz als auch den Netzwerk-Overhead reduzieren. Wenn eine gecachte Antwort nicht frisch ist, kann sie dennoch wiederverwendbar sein, wenn sie durch Validierung aktualisiert werden kann (Abschnitt 4.3) oder wenn der Ursprung nicht verfügbar ist (Abschnitt 4.2.4).
🇮🇹 Italiano
HTTP è tipicamente utilizzato per sistemi informativi distribuiti, dove le prestazioni possono essere migliorate mediante l'uso di cache di risposta. Questo documento definisce gli aspetti di HTTP/1.1 relativi al caching e al riutilizzo dei messaggi di risposta.
Una cache HTTP (HTTP Cache) è un archivio locale di messaggi di risposta e il sottosistema che controlla la memorizzazione, il recupero e la cancellazione dei messaggi in esso contenuti. Una cache memorizza le risposte memorizzabili in cache al fine di ridurre il tempo di risposta e il consumo di larghezza di banda di rete per future richieste equivalenti. Qualsiasi client o server PUÒ (MAY) utilizzare una cache, sebbene una cache non possa essere utilizzata da un server che agisce come tunnel.
Una cache condivisa (Shared Cache) è una cache che memorizza risposte da riutilizzare da più di un utente; le cache condivise sono solitamente (ma non sempre) distribuite come parte di un intermediario. Una cache privata (Private Cache), al contrario, è dedicata a un singolo utente; spesso vengono distribuite come componente di un user agent.
L'obiettivo del caching in HTTP/1.1 è migliorare significativamente le prestazioni riutilizzando un messaggio di risposta precedente per soddisfare una richiesta corrente. Una risposta memorizzata è considerata "fresca" (Fresh), come definito nella Sezione 4.2, se la risposta può essere riutilizzata senza "validazione" (Validation) (controllo con il server di origine per verificare se la risposta memorizzata in cache rimane valida per questa richiesta). Una risposta fresca può quindi ridurre sia la latenza che il sovraccarico di rete ogni volta che viene riutilizzata. Quando una risposta memorizzata in cache non è fresca, potrebbe essere ancora riutilizzabile se può essere aggiornata mediante validazione (Sezione 4.3) o se l'origine non è disponibile (Sezione 4.2.4).
1.1. Conformance and Error Handling (一致性和错误处理)
🇬🇧 English
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
🇨🇳 中文
本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和"OPTIONAL"应按照 [RFC2119] 中的描述进行解释。
关于一致性标准和错误处理的考虑事项在 [RFC7230] 的第2.5节中定义。
🇯🇵 日本語
本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119] に記載されているように解釈されるものとする。
適合性基準およびエラー処理に関する考慮事項は、[RFC7230] のセクション2.5で定義されている。
🇫🇷 Français
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans [RFC2119].
Les critères de conformité et les considérations concernant la gestion des erreurs sont définis dans la Section 2.5 de [RFC7230].
🇩🇪 Deutsch
Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.
Konformitätskriterien und Überlegungen zur Fehlerbehandlung sind in Abschnitt 2.5 von [RFC7230] definiert.
🇮🇹 Italiano
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].
I criteri di conformità e le considerazioni relative alla gestione degli errori sono definiti nella Sezione 2.5 di [RFC7230].
1.2. Syntax Notation (语法标记)
🇬🇧 English
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.
🇨🇳 中文
本规范使用 [RFC5234] 的增强巴科斯-诺尔范式 (ABNF) 标记法，并使用 [RFC7230] 第7节中定义的列表扩展，该扩展允许使用'#'运算符紧凑地定义逗号分隔的列表（类似于'*'运算符表示重复）。附录B描述了从其他文档导入的规则。附录C显示了将所有列表运算符扩展为标准ABNF标记法的收集语法。
🇯🇵 日本語
本仕様は、[RFC5234] の拡張バッカス・ナウア記法 (ABNF) を使用し、[RFC7230] のセクション7で定義されているリスト拡張を使用する。これにより、'#' 演算子を使用してカンマ区切りリストをコンパクトに定義できる（'*' 演算子が繰り返しを示すのと同様）。付録Bは他の文書からインポートされたルールを説明する。付録Cは、すべてのリスト演算子が標準ABNF表記に展開された収集文法を示す。
🇫🇷 Français
Cette spécification utilise la notation Forme de Backus-Naur augmentée (ABNF) de [RFC5234] avec une extension de liste, définie dans la Section 7 de [RFC7230], qui permet une définition compacte de listes séparées par des virgules à l'aide d'un opérateur '#' (similaire à la façon dont l'opérateur '*' indique la répétition). L'Annexe B décrit les règles importées d'autres documents. L'Annexe C montre la grammaire collectée avec tous les opérateurs de liste étendus à la notation ABNF standard.
🇩🇪 Deutsch
Diese Spezifikation verwendet die Erweiterte Backus-Naur-Form (ABNF) Notation von [RFC5234] mit einer Listenerweiterung, die in Abschnitt 7 von [RFC7230] definiert ist und eine kompakte Definition von durch Kommas getrennten Listen unter Verwendung eines '#'-Operators ermöglicht (ähnlich wie der '*'-Operator Wiederholung anzeigt). Anhang B beschreibt aus anderen Dokumenten importierte Regeln. Anhang C zeigt die gesammelte Grammatik mit allen auf Standard-ABNF-Notation erweiterten Listenoperatoren.
🇮🇹 Italiano
Questa specifica utilizza la notazione Forma di Backus-Naur Aumentata (ABNF) di [RFC5234] con un'estensione di lista, definita nella Sezione 7 di [RFC7230], che consente una definizione compatta di elenchi separati da virgole utilizzando un operatore '#' (simile al modo in cui l'operatore '*' indica la ripetizione). L'Appendice B descrive le regole importate da altri documenti. L'Appendice C mostra la grammatica raccolta con tutti gli operatori di lista espansi in notazione ABNF standard.
1.2.1. Delta Seconds (增量秒数)
🇬🇧 English
The delta-seconds rule specifies a non-negative integer, representing time in seconds.
delta-seconds = 1*DIGIT
A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be either 2147483648 (2^31) or the greatest positive integer it can conveniently represent.
Note: The value 2147483648 is present for historical reasons, representing infinity (over 68 years) rather than being stored in binary form; implementations can generate it as a fixed string when any overflow occurs, even if the arithmetic type being used for calculations cannot represent that number directly. What matters here is that overflow has been detected and is not subsequently treated as a negative value.
🇨🇳 中文
delta-seconds规则指定一个非负整数，表示以秒为单位的时间。
delta-seconds = 1*DIGIT
接收方在解析delta-seconds值并将其转换为二进制形式时，应使用至少31位非负整数范围的算术类型。如果缓存接收到的delta-seconds值大于它能表示的最大整数，或者其后续计算发生溢出，则缓存必须 (MUST) 将该值视为2147483648 (2^31) 或它能方便表示的最大正整数。
注意: 值2147483648出于历史原因存在，实际上代表无穷大（超过68年），并且不需要以二进制形式存储; 即使计算使用的算术类型无法直接表示该数字，实现也可以在发生任何溢出时将其作为固定字符串生成。这里重要的是检测到溢出，并且在后续计算中不将其视为负值。
🇯🇵 日本語
delta-secondsルールは、秒単位の時間を表す非負整数を指定する。
delta-seconds = 1*DIGIT
delta-seconds値を解析してバイナリ形式に変換する受信者は、少なくとも31ビットの非負整数範囲の算術型を使用すべきである (ought to)。キャッシュが表現できる最大整数よりも大きいdelta-seconds値を受信した場合、またはその後の計算でオーバーフローが発生した場合、キャッシュはその値を2147483648 (2^31) または便利に表現できる最大の正整数と見なさなければならない (MUST)。
注: 値2147483648は歴史的な理由で存在し、バイナリ形式で保存されるのではなく、無限大（68年以上）を表す; 計算に使用される算術型がその数値を直接表現できない場合でも、実装はオーバーフローが発生したときにそれを固定文字列として生成できる。ここで重要なのは、オーバーフローが検出され、その後負の値として扱われないことである。
🇫🇷 Français
La règle delta-seconds spécifie un entier non négatif, représentant le temps en secondes.
delta-seconds = 1*DIGIT
Un destinataire analysant une valeur delta-seconds et la convertissant en forme binaire devrait (ought to) utiliser un type arithmétique d'au moins 31 bits de plage d'entiers non négatifs. Si un cache reçoit une valeur delta-seconds supérieure au plus grand entier qu'il peut représenter, ou si l'un de ses calculs ultérieurs déborde, le cache DOIT (MUST) considérer la valeur comme étant soit 2147483648 (2^31), soit le plus grand entier positif qu'il peut commodément représenter.
Remarque : La valeur 2147483648 est présente pour des raisons historiques, représentant l'infini (plus de 68 ans) plutôt que d'être stockée sous forme binaire ; les implémentations peuvent la générer sous forme de chaîne fixe lorsqu'un débordement se produit, même si le type arithmétique utilisé pour les calculs ne peut pas représenter directement ce nombre. Ce qui importe ici, c'est que le débordement a été détecté et n'est pas par la suite traité comme une valeur négative.
🇩🇪 Deutsch
Die delta-seconds-Regel gibt eine nicht-negative Ganzzahl an, die die Zeit in Sekunden darstellt.
delta-seconds = 1*DIGIT
Ein Empfänger, der einen delta-seconds-Wert analysiert und in binäre Form umwandelt, sollte (ought to) einen arithmetischen Typ von mindestens 31 Bits nicht-negativem Ganzzahlbereich verwenden. Wenn ein Cache einen delta-seconds-Wert erhält, der größer als die größte Ganzzahl ist, die er darstellen kann, oder wenn eine seiner nachfolgenden Berechnungen überläuft, MUSS (MUST) der Cache den Wert entweder als 2147483648 (2^31) oder als die größte positive Ganzzahl betrachten, die er bequem darstellen kann.
Hinweis: Der Wert 2147483648 ist aus historischen Gründen vorhanden und repräsentiert Unendlichkeit (über 68 Jahre), anstatt in binärer Form gespeichert zu werden; Implementierungen können ihn als feste Zeichenfolge generieren, wenn ein Überlauf auftritt, selbst wenn der für Berechnungen verwendete arithmetische Typ diese Zahl nicht direkt darstellen kann. Was hier wichtig ist, ist, dass der Überlauf erkannt wurde und anschließend nicht als negativer Wert behandelt wird.
🇮🇹 Italiano
La regola delta-seconds specifica un intero non negativo, che rappresenta il tempo in secondi.
delta-seconds = 1*DIGIT
Un destinatario che analizza un valore delta-seconds e lo converte in forma binaria dovrebbe (ought to) utilizzare un tipo aritmetico di almeno 31 bit di intervallo di interi non negativi. Se una cache riceve un valore delta-seconds maggiore del più grande intero che può rappresentare, o se uno dei suoi calcoli successivi va in overflow, la cache DEVE (MUST) considerare il valore come 2147483648 (2^31) o il più grande intero positivo che può comodamente rappresentare.
Nota: Il valore 2147483648 è presente per ragioni storiche, rappresentando l'infinito (oltre 68 anni) piuttosto che essere memorizzato in forma binaria; le implementazioni possono generarlo come stringa fissa quando si verifica un overflow, anche se il tipo aritmetico utilizzato per i calcoli non può rappresentare direttamente quel numero. Ciò che conta qui è che l'overflow è stato rilevato e non viene successivamente trattato come un valore negativo.
📝 翻译说明 (Translation Notes)
- RFC 2119关键词: 所有语言版本都保留了英文关键词（MUST, SHALL等），因为这些是RFC标准术语
- 专业术语: Cache, Fresh, Validation等核心概念在各语言中采用了双语标注
- 法语: 遵循法语标点规范（冒号前保留空格）
- 德语: 名词首字母大写（Cache, Server等）
- 日语: 使用半角标点，MUST/SHOULD等术语按RFC翻译惯例处理