Zum Hauptinhalt springen

4. Constructing Responses from Caches (Konstruktion von Antworten aus Caches)

Wenn eine Anfrage präsentiert wird, darf (MUST NOT) ein Cache eine gespeicherte Antwort nur dann wiederverwenden, wenn alle folgenden Bedingungen erfüllt sind:

  • Die präsentierte Ziel-URI (siehe Abschnitt 7.1 von [HTTP]) stimmt mit der Ziel-URI der gespeicherten Antwort überein, und

  • Die mit der gespeicherten Antwort verbundene Anfragemethode erlaubt deren Verwendung für die präsentierte Anfrage, und

  • Die durch die gespeicherte Antwort spezifizierten Anfrage-Header-Felder (falls vorhanden) stimmen mit denen der präsentierten Anfrage überein (siehe Abschnitt 4.1), und

  • Die gespeicherte Antwort enthält keine no-cache-Direktive (Abschnitt 5.2.2.4), es sei denn, sie wurde erfolgreich validiert (Abschnitt 4.3), und

  • Die gespeicherte Antwort ist eine der folgenden:

    • Frisch (siehe Abschnitt 4.2), oder

    • Darf als veraltet bereitgestellt werden (siehe Abschnitt 4.2.4), oder

    • Erfolgreich validiert (siehe Abschnitt 4.3).

Beachten Sie, dass Cache-Erweiterungen jede der oben aufgeführten Anforderungen überschreiben können; siehe Abschnitt 5.2.3.

Bei Verwendung einer gespeicherten Antwort zur Erfüllung einer Anfrage ohne Validierung muss (MUST) ein Cache ein Age-Header-Feld (Abschnitt 5.1) generieren und dabei jedes in der Antwort vorhandene Age-Feld durch einen Wert ersetzen, der dem current_age der gespeicherten Antwort entspricht; siehe Abschnitt 4.2.3.

Ein Cache muss (MUST) Anfragen mit unsicheren Methoden (siehe Abschnitt 9.2.1 von [HTTP]) direkt an den Ursprungsserver weiterleiten; d.h., ein Cache darf keine Antwort auf eine solche Anfrage generieren, bevor er die Anfrage weitergeleitet und eine entsprechende Antwort erhalten hat.

Beachten Sie auch, dass unsichere Anfragen gespeicherte Antworten ungültig machen können; siehe Abschnitt 4.4.

Ein Cache kann (MAY) eine gespeicherte oder speicherbare Antwort verwenden, um mehrere Anfragen zu erfüllen, vorausgesetzt, die Antwort darf für die betreffenden Anfragen wiederverwendet werden. Dies ermöglicht es Caches, "Anfragen zu kollabieren (Collapse Requests)" -- oder mehrere eingehende Anfragen während eines Cache-Misses zu einer einzigen Weiterleitungsanfrage zu kombinieren -- und dadurch die Last auf dem Ursprungsserver und Netzwerk zu reduzieren. Beachten Sie jedoch, dass, wenn der Cache die zurückgegebene Antwort nicht für einige oder alle kollabierten Anfragen verwenden kann, er diese Anfragen weiterleiten muss, um sie zu erfüllen, was zusätzliche Latenz einführen kann.

Wenn mehrere geeignete Antworten gespeichert sind, muss (MUST) ein Cache die neueste Antwort verwenden (wie durch das Date-Header-Feld bestimmt). Er kann auch die Anfrage mit "Cache-Control: max-age=0" oder "Cache-Control: no-cache" weiterleiten, um zu klären, welche Antwort verwendet werden soll.

Ein Cache ohne Uhr (siehe Abschnitt 5.6.7 von [HTTP]) muss (MUST) gespeicherte Antworten bei jeder Verwendung revalidieren.

4.1 Calculating Cache Keys with the Vary Header Field (Berechnung von Cache-Schlüsseln mit dem Vary-Header-Feld)​

Wenn ein Cache eine Anfrage erhält, die durch eine gespeicherte Antwort erfüllt werden kann, und diese gespeicherte Antwort ein Vary-Header-Feld enthält (siehe Abschnitt 12.5.5 von [HTTP]), darf (MUST NOT) der Cache diese gespeicherte Antwort nicht ohne Revalidierung verwenden, es sei denn, alle durch den Vary-Feldwert nominierten Anfrage-Header-Felder stimmen sowohl in der ursprünglichen Anfrage (d.h. der Anfrage, die das Speichern der Cache-Antwort verursachte) als auch in der präsentierten Anfrage überein.

Die Header-Felder zweier Anfragen sind als übereinstimmend definiert, wenn und nur wenn die Header-Felder der ersten Anfrage in die Header-Felder der zweiten Anfrage transformiert werden können, indem eine der folgenden Operationen angewendet wird:

  • Hinzufügen oder Entfernen von Leerzeichen, wo dies durch die Syntax des Header-Feldes erlaubt ist

  • Kombinieren mehrerer Header-Feldzeilen mit demselben Feldnamen (siehe Abschnitt 5.2 von [HTTP])

  • Normalisierung beider Header-Feldwerte auf eine Weise, die bekanntermaßen identische Semantik hat, gemäß der Spezifikation des Header-Feldes (z.B. Neuordnung von Feldwerten, wenn die Reihenfolge nicht signifikant ist; Groß-/Kleinschreibungsnormalisierung, wenn Werte als nicht case-sensitiv definiert sind)

Wenn ein Header-Feld in einer Anfrage fehlt, kann es nur übereinstimmen, wenn es auch in der anderen Anfrage fehlt.

Eine gespeicherte Antwort mit einem Vary-Header-Feldwert, der das Mitglied "*" enthält, schlägt immer bei der Übereinstimmung fehl.

Wenn mehrere gespeicherte Antworten übereinstimmen, muss ein Cache eine zur Verwendung auswählen. Wenn die nominierten Anfrage-Header-Felder einen bekannten Präferenzordnungsmechanismus haben (z.B. qvalues bei Accept und ähnlichen Anfrage-Header-Feldern), kann (MAY) dieser Mechanismus verwendet werden, um die bevorzugte Antwort auszuwählen. Wenn kein solcher Mechanismus existiert oder zu gleich bevorzugten Antworten führt, wird die neueste Antwort (wie durch das Date-Header-Feld bestimmt) gemäß Abschnitt 4 ausgewählt.

Einige Ressourcen lassen das Vary-Header-Feld fälschlicherweise aus ihrer Standardantwort aus (d.h. derjenigen, die gesendet wird, wenn die Anfrage keine Präferenzen ausdrückt), mit der Wirkung, dass sie für nachfolgende Anfragen an diese Ressource ausgewählt wird, selbst wenn eine bevorzugtere Antwort verfügbar ist. Wenn ein Cache mehrere gespeicherte Antworten für eine Ziel-URI hat und eine oder mehrere das Vary-Header-Feld auslassen, sollte (SHOULD) der Cache die neueste (siehe Abschnitt 4.2.3) gespeicherte Antwort auswählen, die einen gültigen Vary-Feldwert hat.

Wenn keine gespeicherte Antwort übereinstimmt, kann der Cache die präsentierte Anfrage nicht erfüllen. Typischerweise wird die Anfrage an den Ursprungsserver weitergeleitet, möglicherweise mit hinzugefügten Vorbedingungen, um bereits gespeicherte Antworten des Caches zu beschreiben (Abschnitt 4.3).

4.2 Freshness (Frische)​

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

Die "Frischelebensdauer (Freshness Lifetime)" einer Antwort ist die Zeitdauer zwischen ihrer Generierung durch den Ursprungsserver und ihrer Ablaufzeit. Eine "explizite Ablaufzeit (Explicit Expiration Time)" ist der Zeitpunkt, zu dem der Ursprungsserver beabsichtigt, dass ein Cache eine gespeicherte Antwort ohne weitere Validierung nicht mehr verwendet, während eine "heuristische Ablaufzeit (Heuristic Expiration Time)" eine ist, die von einem Cache zugewiesen wird, wenn keine explizite Ablaufzeit verfügbar ist.

Das "Alter (Age)" einer Antwort ist die Zeit, die seit ihrer Generierung oder erfolgreichen Validierung beim Ursprungsserver vergangen ist.

Wenn eine Antwort frisch ist, kann sie verwendet werden, um nachfolgende 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 der Ursprungsserver eine explizite Ablaufzeit in der Zukunft bereitstellt, entweder mit dem Expires-Header-Feld (Abschnitt 5.3) oder der max-age-Antwort-Direktive (Abschnitt 5.2.2.1). Im Allgemeinen wird ein Ursprungsserver einer Antwort eine explizite Ablaufzeit in der Zukunft zuweisen, in der Annahme, dass sich die Darstellung vor dieser Ablaufzeit wahrscheinlich nicht auf semantisch signifikante Weise ändern wird.

Wenn ein Ursprungsserver erzwingen möchte, dass ein Cache jede Anfrage validiert, kann er eine explizite Ablaufzeit in der Vergangenheit zuweisen, um anzuzeigen, dass die Antwort bereits veraltet ist. Konforme Caches werden normalerweise eine veraltete Cache-Antwort validieren, bevor sie sie wiederverwenden (siehe Abschnitt 4.2.4).

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

Die Berechnung zur Bestimmung, 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 max-age- oder min-fresh-Anfrage-Direktiven (Abschnitt 5.2.1) senden, um Grenzen für die Frischeberechnungen für die entsprechende Antwort vorzuschlagen. Caches sind jedoch nicht verpflichtet, diese zu berücksichtigen.

Bei der Berechnung der Frische, um häufige Probleme beim Parsen von Datumsangaben zu vermeiden:

  • Obwohl alle Datumsformate als case-sensitiv spezifiziert sind, sollten (SHOULD) Cache-Empfänger Feldwerte case-insensitiv abgleichen.

  • Wenn die interne Zeitdarstellung eines Cache-Empfängers eine geringere Auflösung als der Wert des HTTP-date hat, muss (MUST) der Empfänger das geparste Expires-Datum intern als die früheste Zeit darstellen, die gleich oder vor dem empfangenen Wert liegt.

  • Ein Cache-Empfänger darf nicht (MUST NOT) zulassen, dass die lokale Zeitzone die Berechnung oder den Vergleich von Alter oder Ablaufzeiten beeinflusst.

  • Ein Cache-Empfänger sollte (SHOULD) Datumsangaben mit Zeitzonenabkürzungen außer "GMT" als ungültig für die Ablaufberechnung betrachten.

Beachten Sie, dass Frische nur für Cache-Operationen gilt; sie kann nicht verwendet werden, um einen User-Agent zu zwingen, seine Anzeige zu aktualisieren oder eine Ressource neu zu laden. Siehe Abschnitt 6 für eine Erklärung der Unterschiede zwischen Caches und Verlaufsmechanismen.

4.2.1 Calculating Freshness Lifetime (Berechnung der Frischelebensdauer)​

Ein Cache kann die Frischelebensdauer (bezeichnet als freshness_lifetime) einer Antwort berechnen, indem er die folgenden Regeln auswertet und die erste Übereinstimmung verwendet:

  • Wenn der Cache gemeinsam genutzt wird und die s-maxage-Antwort-Direktive (Abschnitt 5.2.2.10) vorhanden ist, verwende ihren Wert, oder

  • Wenn die max-age-Antwort-Direktive (Abschnitt 5.2.2.1) vorhanden ist, verwende ihren Wert, oder

  • Wenn das Expires-Antwort-Header-Feld (Abschnitt 5.3) vorhanden ist, verwende seinen Wert abzüglich des Wertes des Date-Antwort-Header-Feldes (unter Verwendung der Zeit, zu der die Nachricht empfangen wurde, falls nicht vorhanden, gemäß Abschnitt 6.6.1 von [HTTP]), oder

  • Andernfalls ist keine explizite Ablaufzeit in der Antwort vorhanden. Eine heuristische Frischelebensdauer könnte anwendbar sein; siehe Abschnitt 4.2.2.

Beachten Sie, dass diese Berechnung darauf abzielt, Uhrenabweichungen zu reduzieren, indem so weit wie möglich Informationen von der Uhr des Ursprungsservers verwendet werden.

Wenn es mehrere Vorkommen einer bestimmten Direktive gibt (z.B. zwei Expires-Header-Feldzeilen oder mehrere Cache-Control: max-age-Direktiven), sollte entweder das erste Vorkommen verwendet werden oder die Antwort als veraltet betrachtet werden. Wenn Direktiven in Konflikt stehen (z.B. sind sowohl max-age als auch no-cache vorhanden), sollte die restriktivste Direktive berücksichtigt werden. Caches werden ermutigt, Antworten mit ungültigen Frischeinformationen (z.B. eine max-age-Direktive mit nicht-ganzzahligem Inhalt) als veraltet zu betrachten.

4.2.2 Calculating Heuristic Freshness (Berechnung heuristischer Frische)​

Da Ursprungsserver nicht immer explizite Ablaufzeiten bereitstellen, kann (MAY) ein Cache eine heuristische Ablaufzeit zuweisen, wenn keine explizite Zeit angegeben ist, unter Verwendung eines Algorithmus, der andere Header-Feldwerte (wie die Last-Modified-Zeit) verwendet, um eine plausible Ablaufzeit zu schätzen. Diese Spezifikation stellt keinen spezifischen Algorithmus bereit, legt aber Worst-Case-Beschränkungen für seine Ergebnisse fest.

Ein Cache darf nicht (MUST NOT) Heuristiken verwenden, um Frische zu bestimmen, wenn eine explizite Ablaufzeit in einer gespeicherten Antwort vorhanden ist. Da die Anforderung von Abschnitt 3 bedeutet, dass Heuristiken nur bei Antworten ohne explizite Frische verwendet werden können, die entweder durch ihren Statuscode als heuristisch cachebar erlaubt sind (siehe z.B. Abschnitt 15.1 von [HTTP]) oder als explizit cachebar markiert wurden (z.B. mit einer public-Antwort-Direktive).

Beachten Sie, dass in früheren Spezifikationen heuristisch cachebare Antwort-Statuscodes als "standardmäßig cachebar (Cacheable by Default)" bekannt waren.

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

Hinweis: Frühere Versionen der HTTP-Spezifikation ([RFC2616], Abschnitt 13.9) verboten Caches, heuristische Frische für URIs mit Abfragekomponenten (d.h. solche, die "?" enthalten) zu berechnen. In der Praxis wurde dies nicht weit verbreitet implementiert. Daher wird Ursprungsservern empfohlen, explizite Direktiven (z.B. Cache-Control: no-cache) zu senden, wenn sie das Caching verhindern möchten.

4.2.3 Calculating Age (Berechnung des Alters)​

Das Age-Header-Feld wird verwendet, um ein geschätztes Alter der Antwortnachricht zu übermitteln, wenn sie aus einem Cache abgerufen wurde. Der Age-Feldwert ist die Schätzung des Caches für die Anzahl der Sekunden seit der Generierung oder Validierung der Antwort beim Ursprungsserver. Somit ist der Age-Wert die Summe der Zeit, die die Antwort in jedem Cache entlang des Pfades vom Ursprungsserver bis zur Ankunft verbracht hat, plus die Zeit, die im Transit entlang des Netzwerkpfades verbracht wurde.

Die folgenden Daten werden für die Altersberechnung verwendet:

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

date_value Der Begriff "date_value" bezeichnet den Wert des Date-Header-Feldes in einer für arithmetische Operationen geeigneten Form. Siehe Abschnitt 6.6.1 von [HTTP] für die Definition des Date-Header-Feldes und Anforderungen für Antworten ohne dieses.

now Der Begriff "now" bezeichnet den aktuellen Wert der Uhr dieser Implementierung (siehe Abschnitt 5.6.7 von [HTTP]).

request_time Der Wert der Uhr zum Zeitpunkt der Anfrage, die zur gespeicherten Antwort führte.

response_time Der Wert der Uhr zum Zeitpunkt des Empfangs der Antwort.

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 Uhr der Implementierung einigermaßen gut mit der Uhr des Ursprungsservers synchronisiert ist. Wenn das Ergebnis negativ ist, wird es durch Null ersetzt.

  2. Der "corrected_age_value", wenn alle Caches entlang des Antwortpfades HTTP/1.1 oder höher implementieren. Ein Cache muss (MUST) diesen Wert relativ zum Zeitpunkt der Initiierung der Anfrage interpretieren, nicht zum Zeitpunkt des Empfangs der Antwort.

apparent_age = max(0, response_time - date_value);

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

Der corrected_age_value kann (MAY) als corrected_initial_age verwendet werden. In Fällen, in denen es sehr alte Cache-Implementierungen geben könnte, die Age nicht ordnungsgemäß einfügen, kann der corrected_initial_age konservativer berechnet werden als

corrected_initial_age = max(apparent_age, corrected_age_value);

Das current_age einer gespeicherten Antwort kann dann berechnet werden, indem die Zeit (in Sekunden) seit der letzten Validierung der gespeicherten Antwort durch den Ursprungsserver zum corrected_initial_age addiert wird.

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

4.2.4 Serving Stale Responses (Bereitstellung veralteter Antworten)​

Eine "veraltete (Stale)" Antwort ist eine, die entweder explizite Ablaufinformationen hat oder die Berechnung heuristischer Ablaufzeiten erlaubt und gemäß der Berechnung in Abschnitt 4.2 nicht frisch ist.

Ein Cache darf nicht (MUST NOT) eine veraltete Antwort generieren, wenn dies durch eine explizite Protokoll-Direktive verboten ist (z.B. durch eine no-cache-Antwort-Direktive, eine must-revalidate-Antwort-Direktive oder eine anwendbare s-maxage- oder proxy-revalidate-Antwort-Direktive; siehe Abschnitt 5.2.2).

Ein Cache darf nicht (MUST NOT) eine veraltete Antwort generieren, es sei denn, der Cache ist getrennt oder sie wird explizit vom Client oder Ursprungsserver erlaubt (z.B. durch die max-stale-Anfrage-Direktive in Abschnitt 5.2.1, durch eine in [RFC5861] definierte Erweiterungs-Direktive oder durch Konfiguration gemäß einem Out-of-Band-Vertrag).

4.3 Validation (Validierung)​

Wenn ein Cache eine oder mehrere gespeicherte Antworten für eine angeforderte URI hat, aber keine davon bereitstellen kann (z.B. weil sie nicht frisch sind oder keine geeignete ausgewählt werden kann; siehe Abschnitt 4.1), kann er den bedingten Anfragemechanismus (siehe Abschnitt 13 von [HTTP]) in einer weitergeleiteten Anfrage verwenden, um dem nächsten eingehenden Server die Möglichkeit zu geben, eine gültige gespeicherte Antwort zur Verwendung auszuwählen, dabei die gespeicherten Metadaten zu aktualisieren oder die gespeicherte(n) Antwort(en) durch eine neue Antwort zu ersetzen. Dieser Prozess ist als "Validierung (Validating)" oder "Revalidierung (Revalidating)" der gespeicherten Antwort bekannt.

4.3.1 Sending a Validation Request (Senden einer Validierungsanfrage)​

Bei der Generierung einer bedingten Anfrage zur Validierung beginnt ein Cache entweder mit einer Anfrage, die er zu erfüllen versucht, oder -- wenn er unabhängig eine Anfrage initiiert -- synthetisiert eine Anfrage unter Verwendung einer gespeicherten Antwort, indem er die Methode, die Ziel-URI und die durch das Vary-Header-Feld identifizierten Anfrage-Header-Felder kopiert (Abschnitt 4.1).

Dann aktualisiert er diese Anfrage mit einem oder mehreren Vorbedingungen-Header-Feldern. Diese enthalten Validator-Metadaten, die aus gespeicherten Antworten für dieselbe URI erhalten wurden. Typischerweise umfasst dies nur gespeicherte Antworten mit demselben Cache-Schlüssel, obwohl ein Cache berechtigt ist, Antworten zu validieren, die er nicht mit den präsentierten Anfrage-Header-Feldern auswählen kann (siehe Abschnitt 4.1).

Der Empfänger vergleicht dann die Vorbedingungen-Header-Felder, um festzustellen, ob eine gespeicherte Antwort einer aktuellen Darstellung der Ressource entspricht.

Ein solcher Validator ist der in einem Last-Modified-Header-Feld (siehe Abschnitt 8.8.2 von [HTTP]) angegebene Zeitstempel, der in einem If-Modified-Since-Header-Feld für die Antwortvalidierung oder in einem If-Unmodified-Since- oder If-Range-Header-Feld für die Darstellungsauswahl verwendet werden kann (d.h., der Client bezieht sich speziell auf eine zuvor erhaltene Darstellung mit diesem Zeitstempel).

Ein weiterer Validator ist das Entity-Tag, das in einem ETag-Feld angegeben ist (siehe Abschnitt 8.8.3 von [HTTP]). Ein oder mehrere Entity-Tags (die eine oder mehrere gespeicherte Antworten angeben) können in einem If-None-Match-Header-Feld für die Antwortvalidierung oder in einem If-Match- oder If-Range-Header-Feld für die Darstellungsauswahl verwendet werden (d.h., der Client bezieht sich speziell auf eine oder mehrere zuvor erhaltene Darstellung(en) mit den aufgelisteten Entity-Tags).

Bei der Generierung einer bedingten Anfrage zur Validierung:

  • Muss (MUST) ein Cache das relevante Entity-Tag (unter Verwendung von If-Match, If-None-Match oder If-Range) senden, wenn ein Entity-Tag in der zu validierenden gespeicherten Antwort bereitgestellt wird.

  • Sollte (SHOULD) ein Cache den Last-Modified-Wert (unter Verwendung von If-Modified-Since) senden, wenn die Anfrage nicht für einen Teilbereich ist, eine einzelne gespeicherte Antwort validiert wird und diese Antwort einen Last-Modified-Wert enthält.

  • Kann (MAY) ein Cache den Last-Modified-Wert (unter Verwendung von If-Unmodified-Since oder If-Range) senden, wenn die Anfrage für einen Teilbereich ist, eine einzelne gespeicherte Antwort validiert wird und diese Antwort nur einen Last-Modified-Wert (anstelle eines Entity-Tags) enthält.

In den meisten Fällen werden beide Validatoren in Cache-Validierungsanfragen generiert, selbst wenn Entity-Tags eindeutig überlegen sind, um alten Vermittlern, die Entity-Tag-Vorbedingungen nicht verstehen, die angemessene Reaktion zu ermöglichen.

4.3.2 Handling a Received Validation Request (Behandlung einer empfangenen Validierungsanfrage)​

Jeder Client in einer Anfragekette kann seinen eigenen Cache haben, daher ist es üblich, dass ein Cache einer Zwischenstation bedingte Anfragen von anderen (ausgehenden) Caches erhält. Ebenso stellen einige User-Agents bedingte Anfragen, um den Datentransfer auf kürzlich geänderte Darstellungen zu beschränken oder teilweise Abrufe zu vervollständigen.

Wenn ein Cache eine Anfrage erhält, die durch Wiederverwendung einer gespeicherten 200 (OK)- oder 206 (Partial Content)-Antwort erfüllt werden kann (gemäß Abschnitt 4), sollte (SHOULD) der Cache alle anwendbaren bedingten Header-Feld-Vorbedingungen, die in dieser Anfrage empfangen wurden, in Bezug auf die entsprechenden in der gespeicherten Antwort enthaltenen Validatoren bewerten.

Ein Cache darf nicht (MUST NOT) bedingte Header-Felder bewerten, die nur auf einen Ursprungsserver anwendbar sind, in einer Anfrage auftreten, deren Semantik nicht mit einer Cache-Antwort erfüllt werden kann, oder in einer Anfrage für eine Zielressource auftreten, für die er keine gespeicherte Antwort hat; solche Vorbedingungen könnten für einen anderen (eingehenden) Server bestimmt sein.

Die ordnungsgemäße Bewertung einer bedingten Anfrage durch einen Cache hängt von den empfangenen Vorbedingungen-Header-Feldern und ihrer Präzedenz ab. Zusammenfassend sind die bedingten Header-Felder If-Match und If-Unmodified-Since nicht auf einen Cache anwendbar, und If-None-Match hat Vorrang vor If-Modified-Since. Siehe Abschnitt 13.2.2 von [HTTP] für eine vollständige Spezifikation der Vorbedingungenpräzedenz.

Eine Anfrage, die ein If-None-Match-Header-Feld enthält (siehe Abschnitt 13.1.2 von [HTTP]), zeigt an, dass der Client eine oder mehrere seiner eigenen gespeicherten Antworten im Vergleich zur vom Cache ausgewählten gespeicherten Antwort validieren möchte (gemäß Abschnitt 4).

Wenn kein If-None-Match-Header-Feld vorhanden ist, zeigt eine Anfrage, die ein If-Modified-Since-Header-Feld enthält (siehe Abschnitt 13.1.3 von [HTTP]), an, dass der Client eine oder mehrere seiner eigenen gespeicherten Antworten nach Änderungsdatum validieren möchte.

Wenn eine Anfrage ein If-Modified-Since-Header-Feld enthält und ein Last-Modified-Header-Feld nicht in einer gespeicherten Antwort vorhanden ist, sollte (SHOULD) der Cache den Date-Feldwert der gespeicherten Antwort (oder die Zeit, zu der die gespeicherte Antwort empfangen wurde, falls kein Date-Feld vorhanden ist) verwenden, um die Bedingung zu bewerten.

Ein Cache, der Teilantworten auf Bereichsanfragen implementiert (wie in Abschnitt 14.2 von [HTTP] definiert), muss auch ein empfangenes If-Range-Header-Feld (siehe Abschnitt 13.1.5 von [HTTP]) in Bezug auf die vom Cache ausgewählte Antwort bewerten.

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

4.3.3 Handling a Validation Response (Behandlung einer Validierungsantwort)​

Die Cache-Behandlung einer Antwort auf eine bedingte Anfrage hängt von ihrem Statuscode ab:

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

  • Eine vollständige Antwort (d.h. eine mit Inhalt) zeigt an, dass keine der in der bedingten Anfrage nominierten gespeicherten Antworten geeignet ist. Stattdessen muss (MUST) der Cache die vollständige Antwort verwenden, um die Anfrage zu erfüllen. Der Cache kann (MAY) eine solche vollständige Antwort speichern, unterliegt aber seinen Beschränkungen (siehe Abschnitt 3).

  • Wenn jedoch ein Cache eine 5xx (Server Error)-Antwort erhält, während er versucht, eine Antwort zu validieren, kann er entweder diese Antwort an den anfragenden Client weiterleiten oder so handeln, als ob der Server nicht geantwortet hätte. Im letzteren Fall kann (MAY) der Cache eine zuvor gespeicherte Antwort senden, unterliegt aber seinen Beschränkungen dafür (siehe Abschnitt 4.2.4), oder die Validierungsanfrage wiederholen.

4.3.4 Freshening Stored Responses upon Validation (Auffrischung gespeicherter Antworten bei Validierung)​

Wenn ein Cache eine 304 (Not Modified)-Antwort erhält, muss er die gespeicherte(n) Antwort(en) identifizieren, die für die Aktualisierung mit den neuen Informationen geeignet sind, und dies dann tun.

Der anfängliche Satz gespeicherter Antworten zur Aktualisierung sind diejenigen, die für diese Anfrage hätten ausgewählt werden können -- d.h. diejenigen, die die Anforderungen in Abschnitt 4 erfüllen, mit Ausnahme der letzten Anforderung, dass sie frisch sein, als veraltet bereitgestellt werden dürfen oder gerade validiert wurden.

Der anfängliche Satz gespeicherter Antworten wird dann durch die erste der folgenden Übereinstimmungen weiter gefiltert:

  • Wenn die neue Antwort einen oder mehrere "starke Validatoren (Strong Validators)" enthält (siehe Abschnitt 8.8.1 von [HTTP]), dann identifiziert jeder dieser starken Validatoren eine ausgewählte Darstellung zur Aktualisierung. Alle gespeicherten Antworten im anfänglichen Satz, die einen der gleichen starken Validatoren haben, werden zur Aktualisierung identifiziert. Wenn keine im anfänglichen Satz mindestens einen der gleichen starken Validatoren enthält, darf (MUST NOT) der Cache die neue Antwort nicht zur Aktualisierung gespeicherter Antworten verwenden.

  • Wenn die neue Antwort keine starken Validatoren enthält, aber einen oder mehrere "schwache Validatoren (Weak Validators)", und diese Validatoren einer der anfänglichen Menge gespeicherter Antworten entsprechen, dann wird die neueste dieser übereinstimmenden gespeicherten Antworten zur Aktualisierung identifiziert.

  • Wenn die neue Antwort keine Form von Validator enthält (wie im Fall, dass ein Client eine If-Modified-Since-Anfrage aus einer anderen Quelle als dem Last-Modified-Antwort-Header-Feld generiert), und es nur eine gespeicherte Antwort im anfänglichen Satz gibt und diese gespeicherte Antwort auch keinen Validator hat, dann wird diese gespeicherte Antwort zur Aktualisierung identifiziert.

Für jede identifizierte gespeicherte Antwort muss (MUST) der Cache ihre Header-Felder mit den in der 304 (Not Modified)-Antwort bereitgestellten Header-Feldern gemäß Abschnitt 3.2 aktualisieren.

4.3.5 Freshening Responses with HEAD (Auffrischung von Antworten mit HEAD)​

Eine Antwort auf die HEAD-Methode ist identisch mit dem, was eine äquivalente mit GET gemachte Anfrage wäre, außer dass kein Inhalt gesendet wird. Diese Eigenschaft einer HEAD-Antwort kann verwendet werden, um eine Cache-GET-Antwort ungültig zu machen oder zu aktualisieren, wenn der effizientere bedingte GET-Anfragemechanismus nicht verfügbar ist (aufgrund fehlender Validatoren in der gespeicherten Antwort) oder wenn die Übertragung von Inhalt nicht erwünscht ist, selbst wenn er geändert wurde.

Wenn ein Cache eine eingehende HEAD-Anfrage für eine Ziel-URI stellt und eine 200 (OK)-Antwort erhält, sollte (SHOULD) der Cache jede seiner gespeicherten GET-Antworten aktualisieren oder ungültig machen, die für diese Anfrage hätten ausgewählt werden können (siehe Abschnitt 4.1).

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

Wenn der Cache eine gespeicherte Antwort mit Metadaten aus einer HEAD-Antwort aktualisiert, muss (MUST) der Cache die gespeicherte Antwort mit den in der HEAD-Antwort bereitgestellten Header-Feldern aktualisieren (siehe Abschnitt 3.2).

4.4 Invalidating Stored Responses (Ungültigmachen gespeicherter Antworten)​

Da unsichere Anfragemethoden (siehe Abschnitt 9.2.1 von [HTTP]) wie PUT, POST oder DELETE das Potenzial haben, den Zustand auf dem Ursprungsserver zu ändern, müssen dazwischenliegende Caches gespeicherte Antworten ungültig machen, um deren Inhalt auf dem neuesten Stand zu halten.

Wenn ein Cache eine Nicht-Fehler-Statuscode-Antwort auf eine unsichere Anfragemethode erhält (einschließlich Methoden, deren Sicherheit unbekannt ist), muss (MUST) der Cache die Ziel-URI ungültig machen (siehe Abschnitt 7.1 von [HTTP]).

Wenn ein Cache eine Nicht-Fehler-Statuscode-Antwort auf eine unsichere Anfragemethode erhält (einschließlich Methoden, deren Sicherheit unbekannt ist), kann (MAY) der Cache andere URIs ungültig machen. Insbesondere sind die URIs in den Location- und Content-Location-Antwort-Header-Feldern (falls vorhanden) Kandidaten für Ungültigmachung; andere URIs könnten durch in diesem Dokument nicht spezifizierte Mechanismen entdeckt werden. Ein Cache darf jedoch nicht (MUST NOT) Ungültigmachung unter diesen Bedingungen auslösen, wenn der Ursprung (siehe Abschnitt 4.3.1 von [HTTP]) der ungültig zu machenden URI vom Ursprung der Ziel-URI abweicht (siehe Abschnitt 7.1 von [HTTP]). Dies hilft, Denial-of-Service-Angriffe zu verhindern.

"Ungültig machen (Invalidate)" bedeutet, dass der Cache entweder alle gespeicherten Antworten entfernt, deren Ziel-URI mit der angegebenen URI übereinstimmt, oder sie als "ungültig (Invalid)" markiert und eine obligatorische Validierung erfordert, bevor sie als Antwort auf eine nachfolgende Anfrage gesendet werden können.

Eine "Nicht-Fehler-Antwort (Non-Error Response)" ist eine mit einem 2xx (Successful)- oder 3xx (Redirection)-Statuscode.

Beachten Sie, dass dies keine Ungültigmachung aller geeigneten Antworten global garantiert; zustandsändernde Anfragen machen nur Antworten in den Caches ungültig, durch die sie hindurchgehen.

Letztes Update am