2. Gezielte Cache-Control-Header-Felder

Ein Gezieltes Cache-Control-Header-Feld (im Folgenden "gezieltes Feld") ist ein HTTP-Antwort-Header-Feld, das dieselbe Semantik wie das Cache-Control-Antwort-Header-Feld hat ([HTTP-CACHING], Abschnitt 5.2). Es hat jedoch einen eindeutigen Feldnamen, der das Ziel für seine Cache-Direktiven angibt.

Zum Beispiel:

CDN-Cache-Control: max-age=60

ist ein gezieltes Feld, das auf CDNs angewendet wird, wie in Abschnitt 3 definiert.

2.1. Syntax

Gezielte Felder sind Dictionary Structured Fields (Abschnitt 3.2 von [STRUCTURED-FIELDS]). Jedes Mitglied des Dictionary ist eine HTTP-Cache-Antwortdirektive (Abschnitt 5.2.2 von [HTTP-CACHING]) einschließlich Erweiterungs-Antwortdirektiven (gemäß Abschnitt 5.2.3 von [HTTP-CACHING]). Beachten Sie, dass gezielte Felder zwar oft dieselbe Syntax wie Cache-Control-Felder haben, Unterschiede in der Fehlerbehandlung jedoch bedeuten, dass die Verwendung eines Cache-Control-Parsers anstelle eines Structured Fields-Parsers Interoperabilitätsprobleme einführen kann.

Da Cache-Direktiven nicht in Bezug auf strukturierte Datentypen definiert sind, ist es notwendig, ihre Werte den entsprechenden Typen zuzuordnen. Abschnitt 5.2 von [HTTP-CACHING] definiert Cache-Direktiven-Werte als entweder fehlend, eine zitierte Zeichenkette oder ein Token.

Dies bedeutet, dass Cache-Direktiven ohne Wert auf einen Boolean (Abschnitt 3.3.6 von [STRUCTURED-FIELDS]) abgebildet werden. Wenn der Wert eine zitierte Zeichenkette ist, wird sie auf einen String (Abschnitt 3.3.3 von [STRUCTURED-FIELDS]) abgebildet, und wenn es ein Token ist, wird sie auf ein Token (Abschnitt 3.3.4 von [STRUCTURED-FIELDS]), eine Ganzzahl (Abschnitt 3.3.1 von [STRUCTURED-FIELDS]) oder eine Dezimalzahl (Abschnitt 3.3.2 von [STRUCTURED-FIELDS]) abgebildet, abhängig vom Inhalt des Werts.

Beispielsweise hat die Direktive max-age (Abschnitt 5.2.2.1 von [HTTP-CACHING]) einen ganzzahligen Wert; no-store (Abschnitt 5.2.2.5 von [HTTP-CACHING]) hat immer einen booleschen Wert true, und no-cache (Abschnitt 5.2.2.4 von [HTTP-CACHING]) hat einen Wert, der entweder ein boolescher Wert true oder eine Zeichenkette ist, die eine durch Kommas getrennte Liste von Feldnamen enthält.

Implementierungen DÜRFEN KEINE (MUST NOT) Werte generieren, die diese abgeleiteten Einschränkungen für den Wert der Cache-Direktive verletzen. Insbesondere MÜSSEN (MUST) String-Werte, deren erstes Zeichen nicht alphabetisch oder "*" ist, als Strings generiert werden, damit sie nicht mit anderen Typen verwechselt werden.

Implementierungen SOLLTEN NICHT (SHOULD NOT) Werte konsumieren, die diese abgeleiteten Einschränkungen verletzen. Beispielsweise würde eine konsumierende Implementierung, die ein max-age mit einem Dezimalwert in eine Ganzzahl umwandelt, sich anders verhalten als andere Implementierungen, was möglicherweise Interoperabilitätsprobleme verursacht.

Parameter, die bei Cache-Direktiven empfangen werden, sind zu ignorieren, es sei denn, eine andere Behandlung ist ausdrücklich spezifiziert.

Wenn ein gezieltes Feld in einer gegebenen Antwort leer ist oder ein Parsing-Fehler auftritt, MUSS (MUST) dieses Feld vom Cache ignoriert werden (d. h., es verhält sich so, als ob das Feld nicht vorhanden wäre, wahrscheinlich mit einem Fallback auf andere vorhandene Cache-Control-Mechanismen).

2.2. Cache-Verhalten

Ein Cache, der diese Spezifikation implementiert, pflegt eine Zielliste. Eine Zielliste ist eine geordnete Liste der gezielten Feldnamen, die er für die Caching-Richtlinie verwendet, wobei die Reihenfolge die Priorität vom am meisten anwendbaren bis zum am wenigsten anwendbaren widerspiegelt. Die Zielliste kann fest, benutzerkonfigurierbar oder pro Anfrage generiert sein, abhängig von der Implementierung.

Beispielsweise könnte ein CDN-Cache sowohl CDN-Cache-Control als auch einen für diesen CDN spezifischen Header ExampleCDN-Cache-Control unterstützen, wobei letzterer ersteren überschreibt. Seine Zielliste wäre:

[ExampleCDN-Cache-Control, CDN-Cache-Control]

Wenn ein Cache, der diese Spezifikation implementiert, eine Antwort mit einem oder mehreren der Header-Feldnamen in seiner Zielliste empfängt, MUSS (MUST) der Cache das erste (in Ziellistenreihenfolge) Feld mit einem gültigen, nicht leeren Wert auswählen und seinen Wert verwenden, um die Caching-Richtlinie für die Antwort zu bestimmen, und er MUSS (MUST) die Cache-Control- und Expires-Header-Felder in dieser Antwort ignorieren, es sei denn, von den aufgelisteten Header-Feldern ist kein gültiger, nicht leerer Wert verfügbar.

Beachten Sie, dass dies auf einer Antwort-für-Antwort-Basis erfolgt; wenn kein Mitglied der Zielliste des Caches vorhanden, gültig und nicht leer ist, fällt ein Cache auf andere Cache-Control-Mechanismen zurück, wie von HTTP [HTTP-CACHING] gefordert.

Gezielte Felder, die nicht auf der Zielliste eines Caches stehen, DÜRFEN NICHT (MUST NOT) das Verhalten dieses Caches ändern und MÜSSEN (MUST) durchgereicht werden.

Caches, die ein gezieltes Feld verwenden, MÜSSEN (MUST) die Semantik der folgenden Cache-Direktiven implementieren:

• max-age
• must-revalidate
• no-store
• no-cache
• private

Darüber hinaus SOLLTEN (SHOULD) sie andere Cache-Direktiven (einschließlich Erweiterungs-Cache-Direktiven) implementieren, die sie im Cache-Control-Antwort-Header-Feld unterstützen.

Die Semantik und Präzedenz von Cache-Direktiven in einem gezielten Feld sind dieselben wie in Cache-Control. Insbesondere machen no-store und no-cache max-age unwirksam, und nicht erkannte Erweiterungsdirektiven werden ignoriert.

2.3. Interaktion mit HTTP-Frische

HTTP-Caching hat ein einziges End-to-End-Frischemodell, das in Abschnitt 4.2 von [HTTP-CACHING] definiert ist. Wenn zusätzliche Frische-Mechanismen nur für einige Caches entlang eines Anfragepfads verfügbar sind (z. B. unter Verwendung gezielter Felder), müssen ihre Wechselwirkungen sorgfältig berücksichtigt werden. Insbesondere könnte ein gezielter Cache längere Frische-Lebensdauern zur Verfügung haben als andere Caches, was dazu führt, dass er Antworten bereitstellt, die für diese anderen Caches vorzeitig (oder sogar sofort) veraltet erscheinen, was die Cache-Effizienz negativ beeinflusst.

Beispielsweise könnte eine von einem CDN-Cache gespeicherte Antwort mit den folgenden Headern bereitgestellt werden:

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

Aus der Perspektive des CDN ist diese Antwort nach 30 Minuten Caching noch frisch, während sie aus der Sicht anderer Caches bereits veraltet ist. Siehe [AGE-PENALTY] für weitere Diskussion.

Wenn der gezielte Cache einen starken Kohärenzmechanismus hat (z. B. der Origin-Server die Fähigkeit hat, gecachte Antworten proaktiv ungültig zu machen), ist es oft wünschenswert, diese Effekte abzumildern. Einige in Bereitstellungen gesehene Techniken umfassen:

• Entfernen des Age-Header-Felds
• Aktualisieren des Date-Header-Feldwerts auf die aktuelle Zeit
• Aktualisieren des Expires-Header-Feldwerts auf die aktuelle Zeit plus jeden Cache-Control: max-age-Wert

Diese Spezifikation stellt keine spezifischen Anforderungen an Implementierungen, um diese Effekte abzumildern, aber Definitionen gezielter Felder können dies tun.

2.4. Definieren gezielter Felder

Ein89→Ein gezieltes Feld für eine bestimmte Klasse von Caches kann durch Beantragung der Registrierung im "Hypertext Transfer Protocol (HTTP) Field Name Registry" (<https://www.iana.org/assignments/http-fields/>) definiert werden.

Registrierungsanträge können dieses Dokument als Spezifikationsdokument verwenden; in diesem Fall sollte das Kommentarfeld die Klasse der Caches, auf die sich das gezielte Feld bezieht, klar definieren. Alternativ kann, wenn andere Dokumentation für das Feld erstellt wurde, diese als Spezifikationsdokument verwendet werden.

Konventionell haben gezielte Felder das Suffix "-Cache-Control", z. B. "ExampleCDN-Cache-Control". Dieses Suffix DARF jedoch NICHT (MUST NOT) allein verwendet werden, um gezielte Felder zu identifizieren; es ist nur eine Konvention.