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)-Antwortstatuscode 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 Payload-Body) 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 DARF (MAY) eine solche Antwort speichern, vorbehaltlich seiner Einschränkungen (siehe Abschnitt 3).
Wenn ein Cache jedoch eine 5xx (Server Error)-Antwort erhält, während er versucht, eine Antwort zu validieren, kann er diese Antwort entweder an den anfragenden Client weiterleiten oder so tun, als ob der Server nicht reagiert hätte. Im letzteren Fall DARF (MAY) der Cache eine zuvor gespeicherte Antwort senden (siehe Abschnitt 4.2.4).

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

Wenn ein Cache eine 304 (Not Modified)-Antwort erhält, MUSS (MUST) er die Header-Felder der gespeicherten Antwort mit den in der 304-Antwort bereitgestellten Header-Feldern gemäß RFC 7232, Abschnitt 4.1, aktualisieren.

Der Cache MUSS (MUST) auch die aktualisierte gespeicherte Antwort verwenden, um die Anfrage zu erfüllen, die die Validierung verursacht hat, und DARF (MAY) sie verwenden, um andere Anfragen zu erfüllen.

Beim Aktualisieren eines Header-Feldwerts MUSS (MUST) der Cache jedes Warning-Header-Feld in der gespeicherten Antwort mit warn-code 1xx löschen (siehe Abschnitt 5.5) und MUSS (MUST) alle Warning-Header-Felder in der 304-Antwort zur aktualisierten gespeicherten Antwort hinzufügen.

4.3.5. Freshening Responses via HEAD (Auffrischung von Antworten über HEAD)

Eine Antwort auf die HEAD-Methode ist identisch mit dem, was eine gleichwertige Anfrage mit GET gewesen wäre, außer dass ihr ein Body fehlt. Diese Eigenschaft von HEAD-Antworten ermöglicht es einem Cache, eine gespeicherte Antwort zu aktualisieren, ohne den gesamten Antwortinhalt zu übertragen. Daher DARF (MAY) ein Cache eine HEAD-Antwort verwenden, um eine zwischengespeicherte GET-Antwort zu aktualisieren, wenn die HEAD-Antwort Last-Modified- und/oder ETag-Feldwert(e) hat, die mit denen der gespeicherten GET-Antwort übereinstimmen.

Beim Aktualisieren einer gespeicherten Antwort mit einer HEAD-Antwort MUSS (MUST) der Cache die Header-Felder der gespeicherten Antwort mit den in der HEAD-Antwort bereitgestellten Header-Feldwerten aktualisieren.

4.4. Invalidation (Invalidierung)

Der Zweck der Cache-Invalidierung besteht darin, Antworten zu eliminieren, deren tatsächlicher Antwortwert (nicht Header-Felder) wahrscheinlich erheblich von der invalidierten Antwort abweicht, wodurch Verwirrung vermieden wird, wenn die beiden als Alternativen präsentiert werden.

Wenn ein Cache eine Anfrage mit einer Methode erhält, die zu einer Aktualisierung gespeicherter Antworten führen kann (z. B. PUT, POST oder DELETE; siehe Abschnitt 4.2.1 von [RFC7231]), MUSS (MUST) er alle gespeicherten Antworten für den effektiven Anfrage-URI (Abschnitt 5.5 von [RFC7230]) sowie diejenigen für die URIs in den Location- und Content-Location-Antwort-Header-Feldern (falls vorhanden) als invalidiert betrachten.

Ein Cache DARF jedoch NICHT (MUST NOT) einen URI invalidieren, der in den Location- oder Content-Location-Antwort-Header-Feldern erscheint, wenn der Antwortstatuscode eine Weiterleitung ist und die Hostkomponente in diesem URI vom Host des effektiven Anfrage-URI abweicht.

Ein Cache MUSS (MUST) den effektiven Anfrage-URI (Abschnitt 5.5 von [RFC7230]) invalidieren, wenn er eine Nicht-Fehler-Antwort auf eine Anfrage mit einer Methode erhält, deren Semantik impliziert, dass der Zustand der Zielressource möglicherweise geändert wurde (z. B. PUT, POST, DELETE und PATCH).