2. Überblick über den Cache-Betrieb

Ein ordnungsgemäßer Cache-Betrieb bewahrt die Semantik von HTTP-Übertragungen ([RFC7231]) und vermeidet zugleich die Übertragung von Informationen, die bereits im Cache vorliegen. Obwohl Caching eine gänzlich optionale Funktion von HTTP ist (OPTIONAL), kann angenommen werden, dass die Wiederverwendung einer zwischengespeicherten Antwort wünschenswert ist und dass diese Wiederverwendung das Standardverhalten darstellt, sofern keine Anforderung oder lokale Konfiguration dem entgegensteht. Daher konzentrieren sich die HTTP-Cache-Anforderungen darauf, einen Cache daran zu hindern, eine nicht wiederverwendbare Antwort zu speichern oder eine gespeicherte Antwort unangemessen wiederzuverwenden, statt vorzuschreiben, dass Caches bestimmte Antworten stets speichern und wiederverwenden.

Jeder Cache-Eintrag besteht aus einem Cache-Schlüssel und einer oder mehreren HTTP-Antworten, die zu früheren Anfragen mit demselben Schlüssel gehören. Die häufigste Form eines Cache-Eintrags ist ein erfolgreiches Ergebnis einer Abrufanfrage: also eine 200 (OK)-Antwort auf eine GET-Anfrage, die eine Repräsentation der durch das Anforderungsziel identifizierten Ressource enthält (Abschnitt 4.3.1 von [RFC7231]). Es ist jedoch auch möglich, permanente Weiterleitungen, negative Ergebnisse (z. B. 404 (Not Found)), unvollständige Ergebnisse (z. B. 206 (Partial Content)) und Antworten auf andere Methoden als GET zwischenzuspeichern, sofern die Definition der Methode eine solche Zwischenspeicherung zulässt und etwas definiert, das als Cache-Schlüssel geeignet ist.

Der primäre Cache-Schlüssel besteht aus der Anforderungsmethode und der Ziel-URI. Da jedoch heute gebräuchliche HTTP-Caches üblicherweise auf die Zwischenspeicherung von Antworten auf GET beschränkt sind, lehnen viele Caches andere Methoden einfach ab und verwenden nur die URI als primären Cache-Schlüssel.

Wenn ein Anforderungsziel der Inhaltsaushandlung unterliegt, kann sein Cache-Eintrag aus mehreren gespeicherten Antworten bestehen, die sich jeweils durch einen sekundären Schlüssel für die Werte der auswählenden Header-Felder der ursprünglichen Anfrage unterscheiden (Abschnitt 4.1).