Skip to main content

6. History Lists (历史列表)

🇬🇧 English​

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay a representation retrieved earlier in a session.

The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.

This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives (e.g., Cache-Control: no-store).

🇨🇳 中文​

用户代理通常具有历史机制，例如"后退"按钮和历史列表，可用于重新显示会话中较早检索的表示。

新鲜度模型（第4.2节）不一定适用于历史机制。也就是说，历史机制可以显示先前的表示，即使它已经过期。

这并不禁止历史机制告诉用户视图可能已过时，或遵守缓存指令（例如，Cache-Control: no-store）。

🇯🇵 日本語​

ユーザーエージェントには、セッション中に以前に取得した表現を再表示するために使用できる「戻る」ボタンや履歴リストなどの履歴メカニズムがあることが多い。

鮮度モデル（セクション4.2）は、必ずしも履歴メカニズムに適用されるわけではない。つまり、履歴メカニズムは、期限が切れている場合でも、以前の表現を表示できる。

これは、履歴メカニズムがユーザーにビューが古い可能性があることを伝えたり、キャッシュディレクティブ（例えば、Cache-Control: no-store）を尊重することを禁止するものではない。

🇫🇷 Français​

Les agents utilisateurs ont souvent des mécanismes d'historique, tels que des boutons "Retour" et des listes d'historique, qui peuvent être utilisés pour réafficher une représentation récupérée plus tôt dans une session.

Le modèle de fraîcheur (Section 4.2) ne s'applique pas nécessairement aux mécanismes d'historique. C'est-à-dire qu'un mécanisme d'historique peut afficher une représentation précédente même si elle a expiré.

Cela n'empêche pas le mécanisme d'historique d'indiquer à l'utilisateur qu'une vue pourrait être obsolète, ou de respecter les directives de cache (par exemple, Cache-Control : no-store).

🇩🇪 Deutsch​

User-Agents verfügen häufig über Verlaufsmechanismen, wie z. B. "Zurück"-Schaltflächen und Verlaufslisten, die verwendet werden können, um eine früher in einer Sitzung abgerufene Darstellung erneut anzuzeigen.

Das Frische-Modell (Abschnitt 4.2) gilt nicht unbedingt für Verlaufsmechanismen. Das heißt, ein Verlaufsmechanismus kann eine frühere Darstellung anzeigen, auch wenn sie abgelaufen ist.

Dies verbietet dem Verlaufsmechanismus nicht, dem Benutzer mitzuteilen, dass eine Ansicht möglicherweise veraltet ist, oder Cache-Direktiven zu respektieren (z. B. Cache-Control: no-store).

🇮🇹 Italiano​

Gli agenti utente hanno spesso meccanismi di cronologia, come pulsanti "Indietro" e liste di cronologia, che possono essere utilizzati per visualizzare nuovamente una rappresentazione recuperata in precedenza in una sessione.

Il modello di freschezza (Sezione 4.2) non si applica necessariamente ai meccanismi di cronologia. Cioè, un meccanismo di cronologia può visualizzare una rappresentazione precedente anche se è scaduta.

Ciò non impedisce al meccanismo di cronologia di informare l'utente che una vista potrebbe essere obsoleta, o di rispettare le direttive di cache (ad esempio, Cache-Control: no-store).

7. IANA Considerations (IANA注意事项)

🇬🇧 English​

This specification defines two new registries for use by IANA, as outlined in the following sections. Furthermore, it registers previously defined header fields, upgrades their status, and registers previously unregistered MIME types.

🇨🇳 中文​

本规范定义了供IANA使用的两个新注册表，如以下各节所述。此外，它注册了先前定义的头字段，升级了它们的状态，并注册了先前未注册的MIME类型。

🇯🇵 日本語​

この仕様では、以下のセクションで概説されているように、IANAが使用する2つの新しいレジストリを定義する。さらに、以前に定義されたヘッダーフィールドを登録し、そのステータスをアップグレードし、以前に登録されていなかったMIMEタイプを登録する。

🇫🇷 Français​

Cette spécification définit deux nouveaux registres pour l'utilisation par l'IANA, comme indiqué dans les sections suivantes. De plus, elle enregistre des champs d'en-tête précédemment définis, met à niveau leur statut et enregistre des types MIME précédemment non enregistrés.

🇩🇪 Deutsch​

Diese Spezifikation definiert zwei neue Register zur Verwendung durch die IANA, wie in den folgenden Abschnitten dargelegt. Darüber hinaus registriert sie zuvor definierte Header-Felder, aktualisiert ihren Status und registriert zuvor nicht registrierte MIME-Typen.

🇮🇹 Italiano​

Questa specifica definisce due nuovi registri per l'uso da parte dell'IANA, come delineato nelle sezioni seguenti. Inoltre, registra campi di intestazione precedentemente definiti, aggiorna il loro stato e registra tipi MIME precedentemente non registrati.

7.1. Cache Directive Registry (缓存指令注册表)​

🇬🇧 English​

The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at http://www.iana.org/assignments/http-cache-directives.

7.1.1. Procedure (程序)​

A registration MUST include the following fields:

  • Cache Directive Name
  • Pointer to specification text

Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]).

7.1.2. Considerations for New Cache Control Directives (新缓存控制指令的考虑)​

New extension directives ought to consider defining:

  • What it means for a directive to be specified multiple times,
  • When the directive does not take an argument, what it means when an argument is present,
  • When the directive takes an argument, what it means when it is missing.

See also Section 5.2.3.

🇨🇳 中文​

"超文本传输协议（HTTP）缓存指令注册表"定义了缓存指令的命名空间。它已创建并现在维护在 http://www.iana.org/assignments/http-cache-directives。

7.1.1. 程序​

注册必须 (MUST) 包括以下字段:

  • 缓存指令名称
  • 指向规范文本的指针

添加到此命名空间的值需要IETF审查（见 [RFC5226] 的第4.1节）。

7.1.2. 新缓存控制指令的考虑​

新扩展指令应该 (ought to) 考虑定义:

  • 多次指定指令意味着什么，
  • 当指令不带参数时，存在参数意味着什么，
  • 当指令带参数时，缺少参数意味着什么。

另请参见第5.2.3节。

🇯🇵 日本語​

"ハイパーテキスト転送プロトコル（HTTP）キャッシュディレクティブレジストリ"は、キャッシュディレクティブの名前空間を定義する。これは作成され、現在 http://www.iana.org/assignments/http-cache-directives で維持されている。

7.1.1. 手順​

登録には次のフィールドを含めなければならない (MUST):

  • キャッシュディレクティブ名
  • 仕様テキストへのポインタ

この名前空間に追加される値にはIETFレビューが必要である（[RFC5226] のセクション4.1参照）。

7.1.2. 新しいキャッシュ制御ディレクティブの考慮事項​

新しい拡張ディレクティブは、次を定義することを検討すべきである (ought to):

  • ディレクティブが複数回指定されることの意味，
  • ディレクティブが引数を取らない場合、引数が存在することの意味，
  • ディレクティブが引数を取る場合、それが欠けていることの意味。

セクション5.2.3も参照。

🇫🇷 Français​

Le "Registre des directives de cache du protocole de transfert hypertexte (HTTP)" définit l'espace de noms pour les directives de cache. Il a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-cache-directives.

7.1.1. Procédure​

Une inscription DOIT (MUST) inclure les champs suivants :

  • Nom de la directive de cache
  • Pointeur vers le texte de spécification

Les valeurs à ajouter à cet espace de noms nécessitent un examen IETF (voir Section 4.1 de [RFC5226]).

7.1.2. Considérations pour les nouvelles directives de contrôle de cache​

Les nouvelles directives d'extension devraient (ought to) envisager de définir :

  • Ce que cela signifie pour une directive d'être spécifiée plusieurs fois,
  • Lorsque la directive ne prend pas d'argument, ce que cela signifie lorsqu'un argument est présent,
  • Lorsque la directive prend un argument, ce que cela signifie lorsqu'il est manquant.

Voir également Section 5.2.3.

🇩🇪 Deutsch​

Das "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" definiert den Namensraum für Cache-Direktiven. Es wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-cache-directives gepflegt.

7.1.1. Verfahren​

Eine Registrierung MUSS (MUST) die folgenden Felder enthalten:

  • Name der Cache-Direktive
  • Zeiger auf Spezifikationstext

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe Abschnitt 4.1 von [RFC5226]).

7.1.2. Überlegungen für neue Cache-Control-Direktiven​

Neue Erweiterungsdirektiven sollten (ought to) in Betracht ziehen, Folgendes zu definieren:

  • Was es bedeutet, dass eine Direktive mehrfach angegeben wird,
  • Wenn die Direktive kein Argument annimmt, was es bedeutet, wenn ein Argument vorhanden ist,
  • Wenn die Direktive ein Argument annimmt, was es bedeutet, wenn es fehlt.

Siehe auch Abschnitt 5.2.3.

🇮🇹 Italiano​

Il "Registro delle direttive di cache del protocollo di trasferimento ipertestuale (HTTP)" definisce lo spazio dei nomi per le direttive di cache. È stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-cache-directives.

7.1.1. Procedura​

Una registrazione DEVE (MUST) includere i seguenti campi:

  • Nome della direttiva di cache
  • Puntatore al testo della specifica

I valori da aggiungere a questo spazio dei nomi richiedono la revisione IETF (vedere Sezione 4.1 di [RFC5226]).

7.1.2. Considerazioni per le nuove direttive di controllo della cache​

Le nuove direttive di estensione dovrebbero (ought to) considerare di definire:

  • Cosa significa che una direttiva sia specificata più volte,
  • Quando la direttiva non accetta un argomento, cosa significa quando un argomento è presente,
  • Quando la direttiva accetta un argomento, cosa significa quando manca.

Vedere anche Sezione 5.2.3.

8. Security Considerations (安全考虑)

🇬🇧 English​

This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching.

Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.

Furthermore, the following aspects of caching can result in problems:

Timing Attacks (时间攻击)​

Since one of the primary uses of a cache is to optimize performance by avoiding the transfer of information already held in the cache, such optimizations can unfortunately be used to perform timing attacks. Specifically, the ability to detect whether or not a cache has recently been used to access certain resources can reveal patterns in a user's browsing history.

Mitigations include using encrypted connections to prevent third-party observation and careful design to limit the ability of attackers to probe cache state.

Exposure of Sensitive Information (敏感信息暴露)​

Shared caches are by definition accessible to multiple users and potentially multiple organizations. Such caches need to carefully distinguish authorized content from unauthorized content to avoid returning inappropriate responses. Cache implementations need to be careful to strictly respect directives such as private, no-cache, and no-store that might indicate sensitive information.

Poisoning of Caches (缓存污染)​

One of the primary attacks on caches is to "poison" them by introducing bogus responses. The effects of a poisoned cache depend on the cache's treatment of the bogus responses. If a cache treats a bogus response as authoritative, then the cache can be used to serve incorrect information for an extended period.

Cache poisoning can be mitigated by properly validating responses before caching them and using secure connections to prevent man-in-the-middle attacks.

🇨🇳 中文​

本节旨在告知开发人员、信息提供者和用户HTTP缓存特定的已知安全问题。

缓存暴露了额外的潜在漏洞，因为缓存内容代表了恶意利用的有吸引力的目标。因为缓存内容在HTTP请求完成后仍然存在，所以对缓存的攻击可以在用户认为信息已从网络中删除很久之后揭示信息。因此，缓存内容需要作为敏感信息受到保护。

此外，缓存的以下方面可能导致问题:

时间攻击​

由于缓存的主要用途之一是通过避免传输已在缓存中保存的信息来优化性能，因此不幸的是，这种优化可以用于执行时间攻击。具体来说，检测缓存最近是否用于访问某些资源的能力可以揭示用户浏览历史中的模式。

缓解措施包括使用加密连接以防止第三方观察，以及仔细设计以限制攻击者探测缓存状态的能力。

敏感信息暴露​

共享缓存根据定义可以被多个用户和潜在的多个组织访问。此类缓存需要仔细区分授权内容和未授权内容，以避免返回不适当的响应。缓存实现需要小心严格遵守指令，例如private、no-cache和no-store，这些指令可能表示敏感信息。

缓存污染​

对缓存的主要攻击之一是通过引入虚假响应来"污染"它们。污染缓存的影响取决于缓存对虚假响应的处理。如果缓存将虚假响应视为权威响应，则缓存可以用于在较长时间内提供错误信息。

可以通过在缓存响应之前正确验证响应以及使用安全连接来防止中间人攻击来缓解缓存污染。

🇯🇵 日本語​

このセクションは、HTTPキャッシングに特有の既知のセキュリティ上の懸念について、開発者、情報提供者、およびユーザーに通知することを目的としている。

キャッシュは追加の潜在的な脆弱性を露呈する。キャッシュの内容は悪意のある悪用の魅力的なターゲットを表すためである。キャッシュの内容はHTTPリクエストが完了した後も持続するため、キャッシュへの攻撃は、ユーザーが情報がネットワークから削除されたと信じた長い後に情報を明らかにする可能性がある。したがって、キャッシュの内容は機密情報として保護する必要がある。

さらに、キャッシングの以下の側面が問題を引き起こす可能性がある:

タイミング攻撃​

キャッシュの主な用途の1つは、すでにキャッシュに保持されている情報の転送を回避してパフォーマンスを最適化することであるため、残念ながら、このような最適化はタイミング攻撃を実行するために使用される可能性がある。具体的には、キャッシュが最近特定のリソースへのアクセスに使用されたかどうかを検出する能力は、ユーザーのブラウジング履歴のパターンを明らかにする可能性がある。

緩和策には、第三者の観察を防ぐための暗号化された接続の使用と、攻撃者がキャッシュ状態を調査する能力を制限するための慎重な設計が含まれる。

機密情報の露出​

共有キャッシュは定義上、複数のユーザーおよび潜在的に複数の組織がアクセス可能である。このようなキャッシュは、不適切なレスポンスを返すことを避けるために、承認されたコンテンツと承認されていないコンテンツを注意深く区別する必要がある。キャッシュ実装は、機密情報を示す可能性があるprivate、no-cache、no-storeなどのディレクティブを厳密に尊重するように注意する必要がある。

キャッシュの汚染​

キャッシュに対する主要な攻撃の1つは、偽のレスポンスを導入することによってそれらを「汚染」することである。汚染されたキャッシュの影響は、偽のレスポンスに対するキャッシュの処理に依存する。キャッシュが偽のレスポンスを権威あるものとして扱う場合、キャッシュは長期間にわたって誤った情報を提供するために使用される可能性がある。

キャッシュ汚染は、キャッシュする前にレスポンスを適切に検証し、中間者攻撃を防ぐために安全な接続を使用することで軽減できる。

🇫🇷 Français​

Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus spécifiques à la mise en cache HTTP.

Les caches exposent des vulnérabilités potentielles supplémentaires, car le contenu du cache représente une cible attrayante pour l'exploitation malveillante. Étant donné que le contenu du cache persiste après la fin d'une requête HTTP, une attaque sur le cache peut révéler des informations longtemps après qu'un utilisateur pense que les informations ont été supprimées du réseau. Par conséquent, le contenu du cache doit être protégé comme des informations sensibles.

De plus, les aspects suivants de la mise en cache peuvent entraîner des problèmes :

Attaques temporelles​

Puisque l'une des principales utilisations d'un cache est d'optimiser les performances en évitant le transfert d'informations déjà détenues dans le cache, malheureusement, de telles optimisations peuvent être utilisées pour effectuer des attaques temporelles. Plus précisément, la capacité de détecter si un cache a récemment été utilisé ou non pour accéder à certaines ressources peut révéler des modèles dans l'historique de navigation d'un utilisateur.

Les atténuations incluent l'utilisation de connexions cryptées pour empêcher l'observation par des tiers et une conception soigneuse pour limiter la capacité des attaquants à sonder l'état du cache.

Exposition d'informations sensibles​

Les caches partagés sont par définition accessibles à plusieurs utilisateurs et potentiellement à plusieurs organisations. De tels caches doivent soigneusement distinguer le contenu autorisé du contenu non autorisé pour éviter de renvoyer des réponses inappropriées. Les implémentations de cache doivent faire attention à respecter strictement les directives telles que private, no-cache et no-store qui pourraient indiquer des informations sensibles.

Empoisonnement des caches​

L'une des principales attaques contre les caches consiste à les "empoisonner" en introduisant de fausses réponses. Les effets d'un cache empoisonné dépendent du traitement des fausses réponses par le cache. Si un cache traite une fausse réponse comme faisant autorité, alors le cache peut être utilisé pour servir des informations incorrectes pendant une période prolongée.

L'empoisonnement du cache peut être atténué en validant correctement les réponses avant de les mettre en cache et en utilisant des connexions sécurisées pour empêcher les attaques de l'homme du milieu.

🇩🇪 Deutsch​

Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsbedenken informieren, die spezifisch für HTTP-Caching sind.

Caches setzen zusätzliche potenzielle Schwachstellen frei, da der Inhalt des Caches ein attraktives Ziel für böswillige Ausnutzung darstellt. Da Cache-Inhalte nach Abschluss einer HTTP-Anfrage bestehen bleiben, kann ein Angriff auf den Cache Informationen lange nachdem ein Benutzer glaubt, dass die Informationen aus dem Netzwerk entfernt wurden, offenlegen. Daher müssen Cache-Inhalte als sensible Informationen geschützt werden.

Darüber hinaus können die folgenden Aspekte des Cachings zu Problemen führen:

Timing-Angriffe​

Da eine der Hauptverwendungen eines Caches darin besteht, die Leistung zu optimieren, indem die Übertragung von bereits im Cache gehaltenen Informationen vermieden wird, können solche Optimierungen leider verwendet werden, um Timing-Angriffe durchzuführen. Insbesondere kann die Fähigkeit zu erkennen, ob ein Cache kürzlich zum Zugriff auf bestimmte Ressourcen verwendet wurde oder nicht, Muster in der Browsing-Historie eines Benutzers offenbaren.

Abhilfe umfasst die Verwendung verschlüsselter Verbindungen, um Beobachtungen durch Dritte zu verhindern, und sorgfältiges Design, um die Fähigkeit von Angreifern zu begrenzen, den Cache-Zustand zu untersuchen.

Offenlegung sensibler Informationen​

Gemeinsam genutzte Caches sind per Definition für mehrere Benutzer und potenziell mehrere Organisationen zugänglich. Solche Caches müssen sorgfältig autorisierte Inhalte von nicht autorisierten Inhalten unterscheiden, um unangemessene Antworten zu vermeiden. Cache-Implementierungen müssen sorgfältig darauf achten, Direktiven wie private, no-cache und no-store strikt zu respektieren, die auf sensible Informationen hinweisen könnten.

Vergiftung von Caches​

Einer der Hauptangriffe auf Caches besteht darin, sie zu "vergiften", indem gefälschte Antworten eingeführt werden. Die Auswirkungen eines vergifteten Caches hängen von der Behandlung der gefälschten Antworten durch den Cache ab. Wenn ein Cache eine gefälschte Antwort als maßgeblich behandelt, kann der Cache über einen längeren Zeitraum zur Bereitstellung falscher Informationen verwendet werden.

Cache-Vergiftung kann gemildert werden, indem Antworten vor dem Caching ordnungsgemäß validiert werden und sichere Verbindungen verwendet werden, um Man-in-the-Middle-Angriffe zu verhindern.

🇮🇹 Italiano​

Questa sezione ha lo scopo di informare sviluppatori, fornitori di informazioni e utenti di problemi di sicurezza noti specifici per il caching HTTP.

Le cache espongono vulnerabilità potenziali aggiuntive, poiché il contenuto della cache rappresenta un obiettivo attraente per lo sfruttamento dannoso. Poiché il contenuto della cache persiste dopo il completamento di una richiesta HTTP, un attacco alla cache può rivelare informazioni molto tempo dopo che un utente crede che le informazioni siano state rimosse dalla rete. Pertanto, il contenuto della cache deve essere protetto come informazioni sensibili.

Inoltre, i seguenti aspetti del caching possono causare problemi:

Attacchi temporali​

Poiché uno degli usi principali di una cache è ottimizzare le prestazioni evitando il trasferimento di informazioni già contenute nella cache, sfortunatamente tali ottimizzazioni possono essere utilizzate per eseguire attacchi temporali. In particolare, la capacità di rilevare se una cache è stata recentemente utilizzata o meno per accedere a determinate risorse può rivelare modelli nella cronologia di navigazione di un utente.

Le mitigazioni includono l'uso di connessioni crittografate per prevenire l'osservazione da parte di terzi e un design accurato per limitare la capacità degli aggressori di sondare lo stato della cache.

Esposizione di informazioni sensibili​

Le cache condivise sono per definizione accessibili a più utenti e potenzialmente a più organizzazioni. Tali cache devono distinguere attentamente il contenuto autorizzato dal contenuto non autorizzato per evitare di restituire risposte inappropriate. Le implementazioni di cache devono fare attenzione a rispettare rigorosamente direttive come private, no-cache e no-store che potrebbero indicare informazioni sensibili.

Avvelenamento delle cache​

Uno dei principali attacchi alle cache consiste nell'"avvelenarle" introducendo risposte false. Gli effetti di una cache avvelenata dipendono dal trattamento delle risposte false da parte della cache. Se una cache tratta una risposta falsa come autorevole, allora la cache può essere utilizzata per servire informazioni errate per un periodo prolungato.

L'avvelenamento della cache può essere mitigato validando correttamente le risposte prima di memorizzarle nella cache e utilizzando connessioni sicure per prevenire attacchi man-in-the-middle.

📝 翻译说明 (Translation Notes)

  • Section 6 History Lists: 与缓存机制的区别在所有语言版本中得到了清晰说明
  • Section 7 IANA Considerations: 注册表管理的标准流程在所有语言中保持法律级严谨性
  • Section 8 Security Considerations:
    • 三大安全威胁（时间攻击、敏感信息暴露、缓存污染）在所有语言版本中得到了全面阐述
    • 缓解措施在所有语言中都得到了准确描述
    • 敏感信息保护的重要性在所有语言版本中得到了强调
Last updated on