1. Introduction (Einführung)

Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Request/Response-Protokoll auf Anwendungsebene, das erweiterbare Semantik und selbstbeschreibende Nachrichten für die flexible Interaktion mit netzwerkbasierten Hypertext-Informationssystemen verwendet. HTTP wird häufig in verteilten Informationssystemen verwendet, in denen die Verwendung von Antwort-Caches (Response Caches) die Leistung verbessern kann. Dieses Dokument definiert Aspekte von HTTP, die sich auf das Caching und die Wiederverwendung von Antwortnachrichten beziehen.

Ein HTTP-"Cache (Cache)" ist ein lokaler Speicher für Antwortnachrichten und das Subsystem, das die Speicherung, den Abruf und das Löschen von Nachrichten darin steuert. Ein Cache speichert cachefähige Antworten, um die Antwortzeit und den Netzwerkbandbreitenverbrauch für zukünftige äquivalente Anfragen zu reduzieren. Jeder Client oder Server kann (MAY) einen Cache verwenden, außer wenn er als Tunnel (Tunnel) fungiert (siehe Abschnitt 3.7 von [HTTP]).

Ein "gemeinsamer Cache (Shared Cache)" ist ein Cache, der Antworten zur Wiederverwendung durch mehrere Benutzer speichert; gemeinsame Caches werden typischerweise (aber nicht immer) als Teil eines Vermittlers (Intermediary) eingesetzt. Im Gegensatz dazu ist ein "privater Cache (Private Cache)" einem einzelnen Benutzer gewidmet; typischerweise werden sie als Komponenten eines User-Agents (User Agent) eingesetzt.

Das Ziel des HTTP-Cachings besteht darin, die Leistung erheblich zu verbessern, indem frühere Antwortnachrichten wiederverwendet werden, um aktuelle Anfragen zu erfüllen. Wie in Abschnitt 4.2 definiert, betrachtet ein Cache eine gespeicherte Antwort als "frisch (Fresh)", wenn er die gespeicherte Antwort ohne "Validierung (Validation)" wiederverwenden kann (d. h. ohne beim Origin-Server zu prüfen, ob die gecachte Antwort für diese Anfrage noch gültig ist). Somit können bei jeder Wiederverwendung einer frischen Antwort durch einen Cache Latenz und Netzwerk-Overhead reduziert werden. Wenn eine gecachte Antwort nicht frisch ist, kann sie dennoch wiederverwendbar sein, wenn die Validierung sie aktualisieren kann (Abschnitt 4.3) oder wenn der Origin-Server nicht verfügbar ist (Abschnitt 4.2.4).

Dieses Dokument ersetzt RFC 7234, mit einer Zusammenfassung der Änderungen in Anhang B.

1.1 Requirements Notation (Anforderungsnotation)

Die Schlüsselwörter "muss (MUST)", "darf nicht (MUST NOT)", "erforderlich (REQUIRED)", "muss (SHALL)", "darf nicht (SHALL NOT)", "sollte (SHOULD)", "sollte nicht (SHOULD NOT)", "empfohlen (RECOMMENDED)", "nicht empfohlen (NOT RECOMMENDED)", "kann (MAY)" und "optional (OPTIONAL)" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Abschnitt 2 von [HTTP] definiert Konformitätskriterien und enthält Überlegungen zur Fehlerbehandlung.

1.2 Syntax Notation (Syntaxnotation)

Diese Spezifikation verwendet die Augmented Backus-Naur Form (ABNF)-Notation von [RFC5234], erweitert um die in [RFC7405] definierte Groß-/Kleinschreibung-empfindliche String-Notation.

Sie verwendet auch die in Abschnitt 5.6.1 von [HTTP] definierte Listenerweiterung, die eine kompakte Definition kommaseparierter Listen unter Verwendung des "#"-Operators ermöglicht (ähnlich wie der "*"-Operator die Wiederholung anzeigt). Anhang A zeigt die gesammelte Grammatik mit allen auf Standard-ABNF-Notation erweiterten Listenoperatoren.

1.2.1 Imported Rules (Importierte Regeln)

Die folgenden Kernregeln sind durch Verweis enthalten, wie in Anhang B.1 von [RFC5234] definiert: DIGIT (dezimal 0-9).

[HTTP] definiert die folgenden Regeln:

HTTP-date     = <HTTP-date, see [HTTP], Section 5.6.7>
OWS           = <OWS, see [HTTP], Section 5.6.3>
field-name    = <field-name, see [HTTP], Section 5.1>
quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
token         = <token, see [HTTP], Section 5.6.2>

1.2.2 Delta Seconds (Delta-Sekunden)

Die Regel delta-seconds gibt eine nicht-negative ganze Zahl 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 konvertiert, sollte (ought to) einen arithmetischen Typ mit mindestens 31 Bit nicht-negativem Ganzzahlbereich verwenden. Wenn ein Cache einen delta-seconds-Wert empfängt, der größer ist als die größte Ganzzahl, die er darstellen kann, oder wenn eine seiner nachfolgenden Berechnungen überläuft, muss (MUST) der Cache diesen Wert als 2147483648 (2^31) oder als die größte positive Ganzzahl behandeln, die er bequem darstellen kann.

Hinweis: Der Wert 2147483648 existiert aus historischen Gründen und stellt Unendlichkeit dar (über 68 Jahre) und muss nicht in binärer Form gespeichert werden; Implementierungen können ihn als Zeichenfolge generieren, auch wenn die Berechnung einen arithmetischen Typ verwendet, der diese Zahl nicht direkt darstellen kann. Was hier wichtig ist, ist, dass der Überlauf erkannt wird, anstatt in nachfolgenden Berechnungen als negativer Wert behandelt zu werden.