4. Aufbau von Antworten aus Caches

Wenn einem Cache eine Anfrage vorgelegt wird, darf er eine gespeicherte Antwort nicht wiederverwenden, es sei denn (MUST NOT):

• die vorgelegte effective request URI (Abschnitt 5.5 von [RFC7230]) und die der gespeicherten Antwort stimmen überein, und

• die der gespeicherten Antwort zugeordnete Anforderungsmethode erlaubt deren Verwendung für die vorgelegte Anfrage, und

• die von der gespeicherten Antwort nominierten auswählenden Header-Felder (falls vorhanden) stimmen mit den vorgelegten überein (siehe Abschnitt 4.1), und

• die vorgelegte Anfrage enthält weder das no-cache-Pragma (Abschnitt 5.4) noch die no-cache-Cache-Direktive (Abschnitt 5.2.1), es sei denn, die gespeicherte Antwort wurde erfolgreich validiert (Abschnitt 4.3), und

• die gespeicherte Antwort enthält nicht die no-cache-Cache-Direktive (Abschnitt 5.2.2.2), es sei denn, sie wurde erfolgreich validiert (Abschnitt 4.3), und

• die gespeicherte Antwort ist entweder:

  • frisch (siehe Abschnitt 4.2), oder

  • darf veraltet ausgeliefert werden (siehe Abschnitt 4.2.4), oder

  • wurde erfolgreich validiert (siehe Abschnitt 4.3).

Beachten Sie, dass jede der oben aufgeführten Anforderungen durch eine Cache-Control-Erweiterung außer Kraft gesetzt werden kann; siehe Abschnitt 5.2.3.

Wenn eine gespeicherte Antwort verwendet wird, um eine Anfrage ohne Validierung zu erfüllen, muss ein Cache ein Header-Feld Age generieren (MUST) (Abschnitt 5.1) und dabei ein in der Antwort vorhandenes Feld durch einen Wert ersetzen, der dem current_age der gespeicherten Antwort entspricht; siehe Abschnitt 4.2.3.

Ein Cache muss Anfragen mit Methoden, die nicht sicher sind (Abschnitt 4.2.1 von [RFC7231]), zum Ursprungsserver durchschreiben (write through) (MUST); d. h. ein Cache darf keine Antwort auf eine solche Anfrage erzeugen, bevor er die Anfrage weitergeleitet und eine entsprechende Antwort empfangen hat.

Beachten Sie außerdem, dass unsichere Anfragen bereits gespeicherte Antworten invalidieren können; siehe Abschnitt 4.4.

Wenn mehr als eine geeignete Antwort gespeichert ist, muss ein Cache die jüngste Antwort verwenden (MUST) (bestimmt durch das Header-Feld Date). Er kann die Anfrage auch mit „Cache-Control: max-age=0" oder „Cache-Control: no-cache" weiterleiten, um eindeutig zu klären, welche Antwort verwendet werden soll.

Ein Cache, der keine Uhr zur Verfügung hat, darf gespeicherte Antworten nicht verwenden, ohne sie bei jeder Verwendung erneut zu validieren (MUST NOT).

4.1. Berechnung sekundärer Schlüssel mit Vary

Wenn ein Cache eine Anfrage empfängt, die durch eine gespeicherte Antwort mit einem Header-Feld Vary (Abschnitt 7.1.4 von [RFC7231]) erfüllt werden kann, darf er diese Antwort nicht verwenden (MUST NOT), es sei denn, alle durch das Header-Feld Vary nominierten auswählenden Header-Felder stimmen sowohl in der ursprünglichen Anfrage (d. h. der der gespeicherten Antwort zugeordneten) als auch in der vorgelegten Anfrage überein.

Die auswählenden Header-Felder zweier Anfragen gelten genau dann als übereinstimmend, wenn die der ersten Anfrage durch Anwendung einer der folgenden Operationen in die der zweiten Anfrage überführt werden können:

• Hinzufügen oder Entfernen von Leerraum, wo die Syntax des Header-Felds dies zulässt,

• Zusammenfassen mehrerer Header-Felder mit demselben Feldnamen (siehe Abschnitt 3.2 von [RFC7230]),

• Normalisieren beider Header-Feldwerte auf eine Weise, die gemäß der Spezifikation des Header-Felds bekanntermaßen identische Semantik hat (z. B. Umsortieren von Feldwerten, wenn die Reihenfolge nicht von Bedeutung ist; Normalisierung der Groß-/Kleinschreibung, wenn Werte als unabhängig von Groß-/Kleinschreibung definiert sind).

Wenn (nach einer eventuell stattfindenden Normalisierung) ein Header-Feld in einer Anfrage fehlt, kann es nur dann mit einer anderen Anfrage übereinstimmen, wenn es auch dort fehlt.

Ein Vary-Header-Feldwert von „*" stimmt niemals überein.

Die gespeicherte Antwort mit übereinstimmenden auswählenden Header-Feldern wird als ausgewählte Antwort bezeichnet.

Wenn mehrere ausgewählte Antworten verfügbar sind (möglicherweise einschließlich Antworten ohne Header-Feld Vary), muss der Cache eine davon zur Verwendung auswählen. Wenn ein auswählendes Header-Feld einen bekannten Mechanismus dafür hat (z. B. qvalues bei Accept und ähnlichen Anforderungs-Header-Feldern), kann dieser Mechanismus verwendet werden (MAY), um bevorzugte Antworten auszuwählen; aus dem Rest wird gemäß Abschnitt 4 die jüngste Antwort verwendet (bestimmt durch das Header-Feld Date).

Wenn keine ausgewählte Antwort verfügbar ist, kann der Cache die vorgelegte Anfrage nicht erfüllen. Üblicherweise wird sie in einer (möglicherweise bedingten; siehe Abschnitt 4.3) Anfrage an den Ursprungsserver weitergeleitet.

4.2. Frische

Eine frische Antwort ist eine, deren Alter ihre Frischelebensdauer noch nicht überschritten hat. Umgekehrt ist eine veraltete Antwort eine, bei der dies der Fall ist.

Die Frischelebensdauer einer Antwort ist die Zeitspanne zwischen ihrer Erzeugung durch den Ursprungsserver und ihrem Ablaufzeitpunkt. Ein expliziter Ablaufzeitpunkt ist der Zeitpunkt, zu dem der Ursprungsserver beabsichtigt, dass eine gespeicherte Antwort vom Cache nicht mehr ohne weitere Validierung verwendet werden kann, während ein heuristischer Ablaufzeitpunkt von einem Cache zugewiesen wird, wenn kein expliziter Ablaufzeitpunkt verfügbar ist.

Das Alter einer Antwort ist die Zeit, die vergangen ist, seit sie vom Ursprungsserver erzeugt oder erfolgreich validiert wurde.

Wenn eine Antwort im Cache „frisch" ist, kann sie verwendet werden, um spätere Anfragen zu erfüllen, ohne den Ursprungsserver zu kontaktieren, wodurch die Effizienz verbessert wird.

Der primäre Mechanismus zur Bestimmung der Frische besteht darin, dass ein Ursprungsserver einen expliziten Ablaufzeitpunkt in der Zukunft bereitstellt, entweder über das Header-Feld Expires (Abschnitt 5.3) oder über die Antwort-Direktive max-age (Abschnitt 5.2.2.8). Im Allgemeinen weisen Ursprungsserver Antworten künftige explizite Ablaufzeitpunkte in der Annahme zu, dass sich die Repräsentation vor Erreichen des Ablaufzeitpunkts wahrscheinlich nicht in semantisch bedeutsamer Weise ändern wird.

Wenn ein Ursprungsserver einen Cache zwingen möchte, jede Anfrage zu validieren, kann er einen expliziten Ablaufzeitpunkt in der Vergangenheit zuweisen, um anzuzeigen, dass die Antwort bereits veraltet ist. Konforme Caches validieren normalerweise eine veraltete zwischengespeicherte Antwort, bevor sie sie für spätere Anfragen wiederverwenden (siehe Abschnitt 4.2.4).

Da Ursprungsserver nicht immer explizite Ablaufzeitpunkte bereitstellen, dürfen Caches unter bestimmten Umständen auch eine Heuristik verwenden, um einen Ablaufzeitpunkt zu bestimmen (siehe Abschnitt 4.2.2).

Die Berechnung zur Feststellung, ob eine Antwort frisch ist, lautet:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime ist in Abschnitt 4.2.1 definiert; current_age ist in Abschnitt 4.2.3 definiert.

Clients können die Cache-Direktiven max-age oder min-fresh in einer Anfrage senden, um die Frischeberechnungen für die entsprechende Antwort einzuschränken oder zu lockern (Abschnitt 5.2.1).

Bei der Berechnung der Frische ist zur Vermeidung häufiger Probleme bei der Datumsanalyse Folgendes zu beachten:

• Obwohl alle Datumsformate als unabhängig von Groß- und Kleinschreibung spezifiziert sind, sollte ein Cache-Empfänger die Namen von Tagen, Wochen und Zeitzonen ohne Unterscheidung von Groß- und Kleinschreibung abgleichen (SHOULD).

• Wenn die interne Zeitimplementierung eines Cache-Empfängers eine geringere Auflösung hat als der Wert eines HTTP-date, muss der Empfänger ein analysiertes Expires-Datum intern als den nächstgelegenen Zeitpunkt darstellen, der gleich oder früher als der empfangene Wert ist (MUST).

• Ein Cache-Empfänger darf nicht zulassen, dass lokale Zeitzonen die Berechnung oder den Vergleich eines Alters oder Ablaufzeitpunkts beeinflussen (MUST NOT).

• Ein Cache-Empfänger sollte ein Datum mit einer Zeitzonenabkürzung, die nicht GMT oder UTC ist, für die Berechnung des Ablaufs als ungültig betrachten (SHOULD).

Beachten Sie, dass Frische nur für den Cache-Betrieb gilt; sie kann nicht verwendet werden, um einen Benutzeragenten zu zwingen, seine Anzeige zu aktualisieren oder eine Ressource neu zu laden. Eine Erläuterung des Unterschieds zwischen Caches und Verlaufsmechanismen finden Sie in Abschnitt 6.

4.2.1. Berechnung der Frischelebensdauer

Ein Cache kann die Frischelebensdauer (bezeichnet als freshness_lifetime) einer Antwort berechnen, indem er die erste Übereinstimmung aus Folgendem verwendet:

• Wenn der Cache gemeinsam genutzt wird und die Antwort-Direktive s-maxage (Abschnitt 5.2.2.9) vorhanden ist, deren Wert verwenden, oder

• wenn die Antwort-Direktive max-age (Abschnitt 5.2.2.8) vorhanden ist, deren Wert verwenden, oder

• wenn das Antwort-Header-Feld Expires (Abschnitt 5.3) vorhanden ist, dessen Wert abzüglich des Werts des Antwort-Header-Felds Date verwenden, oder

• andernfalls ist kein expliziter Ablaufzeitpunkt in der Antwort vorhanden. Eine heuristische Frischelebensdauer könnte anwendbar sein; siehe Abschnitt 4.2.2.

Beachten Sie, dass diese Berechnung nicht anfällig für Taktabweichungen (clock skew) ist, da alle Informationen vom Ursprungsserver stammen.

Wenn für eine gegebene Direktive mehr als ein Wert vorhanden ist (z. B. zwei Header-Felder Expires, mehrere Cache-Control: max-age-Direktiven), gilt der Wert der Direktive als ungültig. Caches werden ermutigt, Antworten mit ungültigen Frischeinformationen als veraltet zu betrachten.

4.2.2. Berechnung der heuristischen Frische

Da Ursprungsserver nicht immer explizite Ablaufzeitpunkte bereitstellen, kann ein Cache einen heuristischen Ablaufzeitpunkt zuweisen (MAY), wenn kein expliziter Zeitpunkt angegeben ist, wobei Algorithmen verwendet werden, die andere Header-Feldwerte (etwa den Zeitpunkt Last-Modified) nutzen, um einen plausiblen Ablaufzeitpunkt zu schätzen. Diese Spezifikation gibt keine spezifischen Algorithmen an, erlegt deren Ergebnissen jedoch Worst-Case-Beschränkungen auf.

Ein Cache darf Heuristiken nicht verwenden, um die Frische zu bestimmen, wenn in der gespeicherten Antwort ein expliziter Ablaufzeitpunkt vorhanden ist (MUST NOT). Aufgrund der Anforderungen in Abschnitt 3 bedeutet dies, dass Heuristiken faktisch nur auf Antworten ohne explizite Frische angewendet werden können, deren Statuscodes standardmäßig als zwischenspeicherbar definiert sind (siehe Abschnitt 6.1 von [RFC7231]), sowie auf diejenigen Antworten ohne explizite Frische, die als ausdrücklich zwischenspeicherbar gekennzeichnet wurden (z. B. mit einer Antwort-Direktive „public").

Wenn die Antwort ein Header-Feld Last-Modified (Abschnitt 2.2 von [RFC7232]) hat, werden Caches ermutigt, einen heuristischen Ablaufwert zu verwenden, der nicht mehr als einen Bruchteil des seit diesem Zeitpunkt verstrichenen Intervalls beträgt. Eine typische Einstellung dieses Bruchteils könnte 10 % sein.

Wenn eine Heuristik zur Berechnung der Frischelebensdauer verwendet wird, sollte ein Cache ein Header-Feld Warning mit 113 warn-code in der Antwort generieren (SHOULD) (siehe Abschnitt 5.5.4), wenn dessen current_age mehr als 24 Stunden beträgt und eine solche Warnung nicht bereits vorhanden ist.

Hinweis: Abschnitt 13.9 von [RFC2616] verbot Caches, für URIs mit Abfragekomponenten (d. h. solchen, die '?' enthalten) eine heuristische Frische zu berechnen. In der Praxis wurde dies nicht weit verbreitet implementiert. Daher werden Ursprungsserver ermutigt, explizite Direktiven zu senden (z. B. Cache-Control: no-cache), wenn sie das Zwischenspeichern ausschließen möchten.

4.2.3. Berechnung des Alters

Das Header-Feld Age wird verwendet, um ein geschätztes Alter der Antwortnachricht zu übermitteln, wenn sie von einem Cache bezogen wird. Der Wert des Felds Age ist die Schätzung des Caches für die Anzahl der Sekunden, seit die Antwort vom Ursprungsserver erzeugt oder validiert wurde. Im Wesentlichen ist der Age-Wert die Summe der Zeit, die die Antwort in jedem der Caches entlang des Pfads vom Ursprungsserver verweilt hat, zuzüglich der Zeit, die sie auf Netzwerkpfaden im Transit war.

Für die Altersberechnung werden die folgenden Daten verwendet:

age_value

Der Begriff „age_value" bezeichnet den Wert des Header-Felds Age (Abschnitt 5.1) in einer für arithmetische Operationen geeigneten Form; oder 0, wenn nicht verfügbar.

date_value

Der Begriff „date_value" bezeichnet den Wert des Header-Felds Date in einer für arithmetische Operationen geeigneten Form. Die Definition des Header-Felds Date und Anforderungen bezüglich Antworten ohne dieses Feld finden Sie in Abschnitt 7.1.1.2 von [RFC7231].

now

Der Begriff „now" bedeutet „der aktuelle Wert der Uhr auf dem Host, der die Berechnung durchführt". Ein Host sollte NTP ([RFC5905]) oder ein ähnliches Protokoll verwenden, um seine Uhren mit der koordinierten Weltzeit zu synchronisieren.

request_time

Der aktuelle Wert der Uhr auf dem Host zum Zeitpunkt, als die Anfrage gestellt wurde, die zur gespeicherten Antwort führte.

response_time

Der aktuelle Wert der Uhr auf dem Host zum Zeitpunkt, als die Antwort empfangen wurde.

Das Alter einer Antwort kann auf zwei völlig unabhängige Weisen berechnet werden:

1. das „apparent_age": response_time minus date_value, wenn die lokale Uhr hinreichend gut mit der Uhr des Ursprungsservers synchronisiert ist. Ist das Ergebnis negativ, wird es durch null ersetzt.

2. das „corrected_age_value", wenn alle Caches entlang des Antwortpfads HTTP/1.1 implementieren. Ein Cache muss diesen Wert relativ zum Zeitpunkt des Anfragebeginns interpretieren, nicht zum Zeitpunkt des Antwortempfangs (MUST).

apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

Diese werden wie folgt kombiniert:

corrected_initial_age = max(apparent_age, corrected_age_value);

es sei denn, der Cache ist vom Wert des Header-Felds Age überzeugt (z. B. weil es keine HTTP/1.0-Hops im Header-Feld Via gibt); in diesem Fall kann das corrected_age_value als corrected_initial_age verwendet werden (MAY).

Der current_age einer gespeicherten Antwort kann dann berechnet werden, indem die Zeit (in Sekunden), seit die gespeicherte Antwort zuletzt vom Ursprungsserver validiert wurde, zum corrected_initial_age addiert wird.

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. Ausliefern veralteter Antworten

Eine „veraltete" Antwort ist eine, die entweder explizite Ablaufinformationen hat oder für die eine heuristische Ablaufberechnung zulässig ist, die aber nach den Berechnungen in Abschnitt 4.2 nicht frisch ist.

Ein Cache darf keine veraltete Antwort generieren, wenn dies durch eine ausdrückliche protokollinterne Direktive untersagt ist (z. B. durch eine Cache-Direktive „no-store" oder „no-cache", eine Cache-Antwortdirektive „must-revalidate" oder eine anwendbare Cache-Antwortdirektive „s-maxage" oder „proxy-revalidate"; siehe Abschnitt 5.2.2) (MUST NOT).

Ein Cache darf keine veralteten Antworten senden, es sei denn, er ist getrennt (d. h. er kann den Ursprungsserver nicht kontaktieren oder anderweitig keinen Weiterleitungsweg finden) oder dies ist ausdrücklich erlaubt (z. B. durch die Anforderungsdirektive max-stale; siehe Abschnitt 5.2.1) (MUST NOT).

Ein Cache sollte in veralteten Antworten ein Header-Feld Warning mit dem 110 warn-code generieren (SHOULD) (siehe Abschnitt 5.5.1). Ebenso sollte ein Cache in veralteten Antworten einen 112 warn-code generieren (SHOULD) (siehe Abschnitt 5.5.3), wenn der Cache getrennt ist.

Ein Cache sollte kein neues Header-Feld Warning generieren, wenn er eine Antwort weiterleitet, die kein Header-Feld Age hat, selbst wenn die Antwort bereits veraltet ist (SHOULD NOT). Ein Cache muss eine Antwort nicht validieren, die lediglich im Transit veraltet ist.

4.3. Validierung

Wenn ein Cache eine oder mehrere gespeicherte Antworten für eine angeforderte URI hat, aber keine davon ausliefern kann (z. B. weil sie nicht frisch sind oder keine ausgewählt werden kann; siehe Abschnitt 4.1), kann er den Mechanismus für bedingte Anfragen [RFC7232] in der weitergeleiteten Anfrage nutzen, um dem nächsten eingehenden Server die Möglichkeit zu geben, eine gültige gespeicherte Antwort zur Verwendung auszuwählen und dabei die gespeicherten Metadaten zu aktualisieren, oder die gespeicherte(n) Antwort(en) durch eine neue Antwort zu ersetzen. Dieser Vorgang wird als „Validierung" oder „Revalidierung" der gespeicherten Antwort bezeichnet.

4.3.1. Senden einer Validierungsanfrage

Beim Senden einer bedingten Anfrage zur Cache-Validierung sendet ein Cache ein oder mehrere Vorbedingungs-Header-Felder mit Validator-Metadaten aus seiner/ seinen gespeicherten Antwort(en), die von den Empfängern anschließend verglichen werden, um festzustellen, ob eine gespeicherte Antwort einer aktuellen Repräsentation der Ressource entspricht.

Ein solcher Validator ist der in einem Header-Feld Last-Modified (Abschnitt 2.2 von [RFC7232]) angegebene Zeitstempel, der in einem Header-Feld If-Modified-Since zur Antwortvalidierung verwendet werden kann, oder in einem Header-Feld If-Unmodified-Since oder If-Range zur Repräsentationsauswahl (d. h. der Client bezieht sich speziell auf eine zuvor erhaltene Repräsentation mit diesem Zeitstempel).

Ein weiterer Validator ist das in einem Header-Feld ETag (Abschnitt 2.3 von [RFC7232]) angegebene Entity-Tag. Ein oder mehrere Entity-Tags, die eine oder mehrere gespeicherte Antworten anzeigen, können in einem Header-Feld If-None-Match zur Antwortvalidierung verwendet werden, oder in einem Header-Feld If-Match oder If-Range zur Repräsentationsauswahl (d. h. der Client bezieht sich speziell auf eine oder mehrere zuvor erhaltene Repräsentationen mit den aufgeführten Entity-Tags).

4.3.2. Behandlung einer empfangenen Validierungsanfrage

Jeder Client in der Anforderungskette kann einen eigenen Cache haben, daher ist es üblich, dass ein Cache bei einem Vermittler bedingte Anfragen von anderen (ausgehenden) Caches empfängt. Ebenso nutzen einige Benutzeragenten bedingte Anfragen, um Datenübertragungen auf kürzlich geänderte Repräsentationen zu beschränken oder die Übertragung einer teilweise abgerufenen Repräsentation abzuschließen.

Wenn ein Cache eine Anfrage empfängt, die durch Wiederverwendung einer seiner gespeicherten 200 (OK)- oder 206 (Partial Content)-Antworten erfüllt werden kann, sollte der Cache alle anwendbaren Vorbedingungen bedingter Header-Felder, die in dieser Anfrage empfangen wurden, in Bezug auf die entsprechenden, in der ausgewählten Antwort enthaltenen Validatoren auswerten (SHOULD). Ein Cache darf bedingte Header-Felder nicht auswerten, die nur für einen Ursprungsserver gelten, die sich in einer Anfrage mit einer Semantik befinden, die nicht durch eine zwischengespeicherte Antwort erfüllt werden kann, oder die auf eine Zielressource angewendet werden, für die er keine gespeicherten Antworten hat (MUST NOT); solche Vorbedingungen sind wahrscheinlich für einen anderen (eingehenden) Server bestimmt.

Die ordnungsgemäße Auswertung bedingter Anfragen durch einen Cache hängt von den empfangenen Vorbedingungs-Header-Feldern und deren Rangfolge ab, wie in Abschnitt 6 von [RFC7232] definiert. Die bedingten Header-Felder If-Match und If-Unmodified-Since sind auf einen Cache nicht anwendbar.

Eine Anfrage mit einem Header-Feld If-None-Match (Abschnitt 3.2 von [RFC7232]) zeigt an, dass der Client eine oder mehrere seiner eigenen gespeicherten Antworten im Vergleich zu der vom Cache ausgewählten gespeicherten Antwort validieren möchte. Wenn der Feldwert „*" ist, oder wenn der Feldwert eine Liste von Entity-Tags ist und mindestens eines davon mit dem Entity-Tag der ausgewählten gespeicherten Antwort übereinstimmt, sollte ein Cache-Empfänger eine 304 (Not Modified)-Antwort generieren (unter Verwendung der Metadaten der ausgewählten gespeicherten Antwort), anstatt diese gespeicherte Antwort zu senden (SHOULD).

Wenn ein Cache beschließt, seine eigenen gespeicherten Antworten für eine Anfrage mit einer If-None-Match-Liste von Entity-Tags zu revalidieren, kann der Cache die empfangene Liste mit einer Liste von Entity-Tags aus seinem eigenen Satz gespeicherter Antworten (frisch oder veraltet) zusammenführen (MAY) und die Vereinigung der beiden Listen als Ersatzwert des Header-Felds If-None-Match in der weitergeleiteten Anfrage senden. Wenn eine gespeicherte Antwort nur Teilinhalt enthält, darf der Cache ihr Entity-Tag nicht in die Vereinigung aufnehmen (MUST NOT), es sei denn, die Anfrage betrifft einen Bereich, der durch diese teilweise gespeicherte Antwort vollständig erfüllt würde. Wenn die Antwort auf die weitergeleitete Anfrage 304 (Not Modified) ist und einen Wert des Header-Felds ETag mit einem Entity-Tag hat, das nicht in der Liste des Clients enthalten ist, muss der Cache eine 200 (OK)-Antwort für den Client generieren (MUST), indem er seine entsprechende gespeicherte Antwort wiederverwendet, wie durch die Metadaten der 304-Antwort aktualisiert (Abschnitt 4.3.4).

Wenn kein Header-Feld If-None-Match vorhanden ist, zeigt eine Anfrage mit einem Header-Feld If-Modified-Since (Abschnitt 3.3 von [RFC7232]) an, dass der Client eine oder mehrere seiner eigenen gespeicherten Antworten nach Änderungsdatum validieren möchte. Ein Cache-Empfänger sollte eine 304 (Not Modified)-Antwort generieren (SHOULD) (unter Verwendung der Metadaten der ausgewählten gespeicherten Antwort), wenn einer der folgenden Fälle zutrifft: 1) die ausgewählte gespeicherte Antwort hat einen Last-Modified-Feldwert, der früher oder gleich dem bedingten Zeitstempel ist; 2) in der ausgewählten gespeicherten Antwort ist kein Feld Last-Modified vorhanden, aber sie hat einen Date-Feldwert, der früher oder gleich dem bedingten Zeitstempel ist; oder 3) weder Last-Modified noch Date sind in der ausgewählten gespeicherten Antwort vorhanden, aber der Cache hat vermerkt, dass sie zu einem Zeitpunkt empfangen wurde, der früher oder gleich dem bedingten Zeitstempel ist.

Ein Cache, der Teilantworten auf Bereichsanfragen implementiert, wie in [RFC7233] definiert, muss außerdem ein empfangenes Header-Feld If-Range (Abschnitt 3.2 von [RFC7233]) in Bezug auf seine ausgewählte gespeicherte Antwort auswerten.

4.3.3. Behandlung einer Validierungsantwort

Die Behandlung einer Antwort auf eine bedingte Anfrage durch den Cache hängt von deren Statuscode ab:

• Ein Antwort-Statuscode 304 (Not Modified) zeigt an, dass die gespeicherte Antwort aktualisiert und wiederverwendet werden kann; siehe Abschnitt 4.3.4.

• Eine vollständige Antwort (d. h. eine mit einem Nutzlastkörper) zeigt an, dass keine der in der bedingten Anfrage nominierten gespeicherten Antworten geeignet ist. Stattdessen muss der Cache die vollständige Antwort verwenden, um die Anfrage zu erfüllen, und kann die gespeicherte(n) Antwort(en) ersetzen (MAY).

• Wenn ein Cache jedoch beim Versuch, eine Antwort zu validieren, eine 5xx (Server Error)-Antwort empfängt, kann er diese Antwort an den anfragenden Client weiterleiten oder sich verhalten, als hätte der Server nicht geantwortet. Im letzteren Fall kann der Cache eine zuvor gespeicherte Antwort senden (MAY) (siehe Abschnitt 4.2.4).

4.3.4. Auffrischen gespeicherter Antworten bei der Validierung

Wenn ein Cache eine 304 (Not Modified)-Antwort empfängt und bereits eine oder mehrere gespeicherte 200 (OK)-Antworten für denselben Cache-Schlüssel hat, muss der Cache feststellen, welche der gespeicherten Antworten durch diese neue Antwort aktualisiert werden, und dann die gespeicherte(n) Antwort(en) mit den in der 304-Antwort bereitgestellten neuen Informationen aktualisieren.

Die zu aktualisierende gespeicherte Antwort wird anhand der ersten Übereinstimmung (falls vorhanden) aus Folgendem bestimmt:

• Wenn die neue Antwort einen starken Validator enthält (siehe Abschnitt 2.1 von [RFC7232]), identifiziert dieser starke Validator die zur Aktualisierung ausgewählte Repräsentation. Alle gespeicherten Antworten mit demselben starken Validator werden ausgewählt. Wenn keine der gespeicherten Antworten denselben starken Validator enthält, darf der Cache die neue Antwort nicht verwenden, um eine gespeicherte Antwort zu aktualisieren (MUST NOT).

• Wenn die neue Antwort einen schwachen Validator enthält und dieser Validator einer der gespeicherten Antworten des Caches entspricht, wird die jüngste dieser übereinstimmenden gespeicherten Antworten zur Aktualisierung ausgewählt.

• Wenn die neue Antwort keine Form von Validator enthält (etwa in dem Fall, in dem ein Client eine If-Modified-Since-Anfrage aus einer anderen Quelle als dem Antwort-Header-Feld Last-Modified erzeugt) und es nur eine gespeicherte Antwort gibt und diese gespeicherte Antwort ebenfalls keinen Validator hat, dann wird diese gespeicherte Antwort zur Aktualisierung ausgewählt.

Wenn eine gespeicherte Antwort zur Aktualisierung ausgewählt wird, muss der Cache (MUST):

• alle Header-Felder Warning in der gespeicherten Antwort mit warn-code 1xx löschen (siehe Abschnitt 5.5);

• alle Header-Felder Warning in der gespeicherten Antwort mit warn-code 2xx beibehalten; und

• andere in der 304 (Not Modified)-Antwort bereitgestellte Header-Felder verwenden, um alle Vorkommen der entsprechenden Header-Felder in der gespeicherten Antwort zu ersetzen.

4.3.5. Auffrischen von Antworten über HEAD

Eine Antwort auf die Methode HEAD ist identisch mit dem, was eine äquivalente mit GET gestellte Anfrage ergeben hätte, außer dass ihr ein Körper fehlt. Diese Eigenschaft von HEAD-Antworten kann genutzt werden, um eine zwischengespeicherte GET-Antwort zu invalidieren oder zu aktualisieren, wenn der effizientere Mechanismus der bedingten GET-Anfrage nicht verfügbar ist (weil keine Validatoren in der gespeicherten Antwort vorhanden sind) oder wenn die Übertragung des Repräsentationskörpers nicht gewünscht ist, selbst wenn er sich geändert hat.

Wenn ein Cache eine eingehende HEAD-Anfrage für ein gegebenes Anforderungsziel stellt und eine 200 (OK)-Antwort empfängt, sollte der Cache jede seiner gespeicherten GET-Antworten aktualisieren oder invalidieren, die für diese Anfrage hätten ausgewählt werden können (SHOULD) (siehe Abschnitt 4.1).

Für jede der gespeicherten Antworten, die hätten ausgewählt werden können, gilt: Wenn die gespeicherte Antwort und die HEAD-Antwort übereinstimmende Werte für alle empfangenen Validator-Felder (ETag und Last-Modified) haben und, wenn die HEAD-Antwort ein Header-Feld Content-Length hat, der Wert von Content-Length mit dem der gespeicherten Antwort übereinstimmt, sollte der Cache die gespeicherte Antwort wie unten beschrieben aktualisieren (SHOULD); andernfalls sollte der Cache die gespeicherte Antwort als veraltet betrachten (SHOULD).

Wenn ein Cache eine gespeicherte Antwort mit den in einer HEAD-Antwort bereitgestellten Metadaten aktualisiert, muss der Cache (MUST):

• alle Header-Felder Warning in der gespeicherten Antwort mit warn-code 1xx löschen (siehe Abschnitt 5.5);

• alle Header-Felder Warning in der gespeicherten Antwort mit warn-code 2xx beibehalten; und

• andere in der HEAD-Antwort bereitgestellte Header-Felder verwenden, um alle Vorkommen der entsprechenden Header-Felder in der gespeicherten Antwort zu ersetzen und neue Header-Felder an die Kopfzeilensektion der gespeicherten Antwort anzuhängen, sofern nicht durch das Header-Feld Cache-Control anderweitig eingeschränkt.

4.4. Invalidierung

Da unsichere Anforderungsmethoden (Abschnitt 4.2.1 von [RFC7231]) wie PUT, POST oder DELETE das Potenzial haben, den Zustand auf dem Ursprungsserver zu ändern, können dazwischenliegende Caches sie nutzen, um ihre Inhalte aktuell zu halten.

Ein Cache muss die effective Request URI (Abschnitt 5.5 von [RFC7230]) sowie die URI(s) in den Antwort-Header-Feldern Location und Content-Location (falls vorhanden) invalidieren (MUST), wenn als Antwort auf eine unsichere Anforderungsmethode ein fehlerfreier Statuscode empfangen wird.

Ein Cache darf jedoch eine URI aus einem Antwort-Header-Feld Location oder Content-Location nicht invalidieren (MUST NOT), wenn der Host-Teil dieser URI vom Host-Teil in der effective request URI (Abschnitt 5.5 von [RFC7230]) abweicht. Dies hilft, Denial-of-Service-Angriffe zu verhindern.

Ein Cache muss die effective request URI (Abschnitt 5.5 von [RFC7230]) invalidieren (MUST), wenn er eine fehlerfreie Antwort auf eine Anfrage mit einer Methode empfängt, deren Sicherheit unbekannt ist.

Hierbei ist eine „fehlerfreie Antwort" eine mit einem Statuscode 2xx (Successful) oder 3xx (Redirection). „Invalidieren" bedeutet, dass der Cache entweder alle gespeicherten Antworten im Zusammenhang mit der effective request URI entfernt oder diese als „ungültig" markiert und als einer obligatorischen Validierung bedürftig kennzeichnet, bevor sie als Antwort auf eine spätere Anfrage gesendet werden können.

Beachten Sie, dass dies nicht garantiert, dass alle geeigneten Antworten invalidiert werden. Beispielsweise kann eine zustandsändernde Anfrage Antworten in den Caches invalidieren, die sie durchläuft, aber relevante Antworten können noch in anderen Caches gespeichert sein, die sie nicht durchlaufen hat.