1. Einleitung (Introduction)
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).
1.1. Konformität und Fehlerbehandlung (Conformance and Error Handling)
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.
1.2. Syntax-Notation (Syntax Notation)
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.
1.2.1. Delta-Sekunden (Delta Seconds)
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.