3. Precondition Header Fields (Vorbedingungsheader-Felder)
Dieser Abschnitt definiert die Syntax und Semantik von HTTP/1.1 Header-Feldern zur Anwendung von Vorbedingungen auf Anfragen. Abschnitt 5 definiert, wann die Vorbedingungen angewendet werden. Abschnitt 6 definiert die Bewertungsreihenfolge, wenn mehr als eine Vorbedingung vorhanden ist.
3.1. If-Match
Das If-Match Header-Feld macht die Anfragemethode davon abhängig, dass der Empfänger-Ursprungsserver entweder mindestens eine aktuelle Darstellung der Zielressource hat, wenn der Feldwert "*" ist, oder eine aktuelle Darstellung der Zielressource hat, die ein Entity-Tag hat, das mit einem Mitglied der Liste von Entity-Tags übereinstimmt, die im Feldwert bereitgestellt werden.
Ein Ursprungsserver MUSS die starke Vergleichsfunktion verwenden, wenn Entity-Tags für If-Match verglichen werden (Abschnitt 2.3.2), da der Client beabsichtigt, dass diese Vorbedingung verhindert, dass die Methode angewendet wird, wenn es Änderungen an den Darstellungsdaten gegeben hat.
If-Match = "*" / 1#entity-tag
Beispiele:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
If-Match wird am häufigsten mit zustandsändernden Methoden (z.B. POST, PUT, DELETE) verwendet, um versehentliche Überschreibungen zu verhindern, wenn mehrere Benutzer-Agenten möglicherweise parallel auf derselben Ressource agieren (d.h. um das Problem der "verlorenen Aktualisierung" zu verhindern). Es kann auch mit sicheren Methoden verwendet werden, um eine Anfrage abzubrechen, wenn die ausgewählte Darstellung nicht mit einer bereits gespeicherten (oder teilweise gespeicherten) aus einer vorherigen Anfrage übereinstimmt.
Ein Ursprungsserver, der ein If-Match Header-Feld empfängt, MUSS die Bedingung vor der Ausführung der Methode bewerten (Abschnitt 5). Wenn der Feldwert "*" ist, ist die Bedingung false, wenn der Ursprungsserver keine aktuelle Darstellung für die Zielressource hat. Wenn der Feldwert eine Liste von Entity-Tags ist, ist die Bedingung false, wenn keines der aufgeführten Tags mit dem Entity-Tag der ausgewählten Darstellung übereinstimmt.
Ein Ursprungsserver DARF die angeforderte Methode NICHT ausführen, wenn eine empfangene If-Match Bedingung als false bewertet wird; stattdessen MUSS der Ursprungsserver entweder a) mit dem Statuscode 412 (Precondition Failed) oder b) mit einem der 2xx (Successful) Statuscodes antworten, wenn der Ursprungsserver verifiziert hat, dass eine Zustandsänderung angefordert wird und der Endzustand bereits im aktuellen Zustand der Zielressource reflektiert wird.
Das If-Match Header-Feld kann von Caches und Vermittlern ignoriert werden, da es nicht auf eine gespeicherte Antwort anwendbar ist.
3.2. If-None-Match
Das If-None-Match Header-Feld macht die Anfragemethode davon abhängig, dass ein Empfänger-Cache oder Ursprungsserver entweder keine aktuelle Darstellung der Zielressource hat, wenn der Feldwert "*" ist, oder eine ausgewählte Darstellung mit einem Entity-Tag hat, das mit keinem der in der Feldwert aufgeführten übereinstimmt.
Ein Empfänger MUSS die schwache Vergleichsfunktion verwenden, wenn Entity-Tags für If-None-Match verglichen werden (Abschnitt 2.3.2), da schwache Entity-Tags für die Cache-Validierung verwendet werden können, auch wenn es Änderungen an den Darstellungsdaten gegeben hat.
If-None-Match = "*" / 1#entity-tag
Beispiele:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
If-None-Match wird hauptsächlich in bedingten GET-Anfragen verwendet, um effiziente Aktualisierungen von Cache-Informationen mit minimalem Transaktions-Overhead zu ermöglichen. Wenn ein Client eine oder mehrere gespeicherte Antworten aktualisieren möchte, die Entity-Tags haben, SOLLTE der Client ein If-None-Match Header-Feld generieren, das eine Liste dieser Entity-Tags enthält, wenn er eine GET-Anfrage stellt; dies ermöglicht es Empfängerservern, eine 304 (Not Modified) Antwort zu senden, um anzuzeigen, wenn eine dieser gespeicherten Antworten mit der ausgewählten Darstellung übereinstimmt.
If-None-Match kann auch mit einem Wert von "*" verwendet werden, um zu verhindern, dass eine unsichere Anfragemethode (z.B. PUT) versehentlich eine vorhandene Darstellung der Zielressource ändert, wenn der Client glaubt, dass die Ressource keine aktuelle Darstellung hat.
Ein Ursprungsserver, der ein If-None-Match Header-Feld empfängt, MUSS die Bedingung vor der Ausführung der Methode bewerten (Abschnitt 5). Wenn der Feldwert "*" ist, ist die Bedingung false, wenn der Ursprungsserver eine aktuelle Darstellung für die Zielressource hat. Wenn der Feldwert eine Liste von Entity-Tags ist, ist die Bedingung false, wenn eines der aufgeführten Tags mit dem Entity-Tag der ausgewählten Darstellung übereinstimmt.
Ein Ursprungsserver DARF die angeforderte Methode NICHT ausführen, wenn die Bedingung als false bewertet wird; stattdessen MUSS der Ursprungsserver entweder a) mit dem Statuscode 304 (Not Modified) antworten, wenn die Anfragemethode GET oder HEAD ist, oder b) mit dem Statuscode 412 (Precondition Failed) für alle anderen Anfragemethoden.
3.3. If-Modified-Since
Das If-Modified-Since Header-Feld macht eine GET- oder HEAD-Anfragemethode davon abhängig, dass das Änderungsdatum der ausgewählten Darstellung neuer ist als das im Feldwert angegebene Datum. Die Übertragung der Daten der ausgewählten Darstellung wird vermieden, wenn sich diese Daten nicht geändert haben.
If-Modified-Since = HTTP-date
Ein Beispiel des Feldes:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Ein Empfänger MUSS If-Modified-Since ignorieren, wenn die Anfrage ein If-None-Match Header-Feld enthält; die Bedingung in If-None-Match wird als genauerer Ersatz für die Bedingung in If-Modified-Since betrachtet, und die beiden werden nur zur Interoperabilität mit älteren Vermittlern kombiniert, die möglicherweise If-None-Match nicht implementieren.
Ein Empfänger MUSS das If-Modified-Since Header-Feld ignorieren, wenn der empfangene Feldwert keine gültige HTTP-date ist oder wenn die Anfragemethode weder GET noch HEAD ist.
If-Modified-Since wird typischerweise für zwei verschiedene Zwecke verwendet: 1) um effiziente Aktualisierungen einer gecachten Darstellung zu ermöglichen, die kein Entity-Tag hat, und 2) um den Umfang eines Web-Durchlaufs auf Ressourcen zu begrenzen, die sich kürzlich geändert haben.
Ein Ursprungsserver, der ein If-Modified-Since Header-Feld empfängt, SOLLTE die Bedingung vor der Ausführung der Methode bewerten (Abschnitt 5). Der Ursprungsserver SOLLTE die angeforderte Methode NICHT ausführen, wenn das letzte Änderungsdatum der ausgewählten Darstellung früher oder gleich dem im Feldwert angegebenen Datum ist; stattdessen SOLLTE der Ursprungsserver eine 304 (Not Modified) Antwort generieren, die nur die Metadaten enthält, die zum Identifizieren oder Aktualisieren einer zuvor gecachten Antwort nützlich sind.
3.4. If-Unmodified-Since
Das If-Unmodified-Since Header-Feld macht die Anfragemethode davon abhängig, dass das letzte Änderungsdatum der ausgewählten Darstellung früher oder gleich dem im Feldwert angegebenen Datum ist. Dieses Feld erfüllt den gleichen Zweck wie If-Match für Fälle, in denen der Benutzer-Agent kein Entity-Tag für die Darstellung hat.
If-Unmodified-Since = HTTP-date
Ein Beispiel des Feldes:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Ein Empfänger MUSS If-Unmodified-Since ignorieren, wenn die Anfrage ein If-Match Header-Feld enthält; die Bedingung in If-Match wird als genauerer Ersatz für die Bedingung in If-Unmodified-Since betrachtet, und die beiden werden nur zur Interoperabilität mit älteren Vermittlern kombiniert, die möglicherweise If-Match nicht implementieren.
Ein Empfänger MUSS das If-Unmodified-Since Header-Feld ignorieren, wenn der empfangene Feldwert keine gültige HTTP-date ist.
If-Unmodified-Since wird am häufigsten mit zustandsändernden Methoden (z.B. POST, PUT, DELETE) verwendet, um versehentliche Überschreibungen zu verhindern, wenn mehrere Benutzer-Agenten möglicherweise parallel auf einer Ressource agieren, die keine Entity-Tags mit ihren Darstellungen liefert (d.h. um das Problem der "verlorenen Aktualisierung" zu verhindern).
Ein Ursprungsserver, der ein If-Unmodified-Since Header-Feld empfängt, MUSS die Bedingung vor der Ausführung der Methode bewerten (Abschnitt 5). Der Ursprungsserver DARF die angeforderte Methode NICHT ausführen, wenn das letzte Änderungsdatum der ausgewählten Darstellung neuer ist als das im Feldwert angegebene Datum; stattdessen MUSS der Ursprungsserver entweder a) mit dem Statuscode 412 (Precondition Failed) oder b) mit einem der 2xx (Successful) Statuscodes antworten, wenn der Ursprungsserver verifiziert hat, dass eine Zustandsänderung angefordert wird und der Endzustand bereits im aktuellen Zustand der Zielressource reflektiert wird.
Das If-Unmodified-Since Header-Feld kann von Caches und Vermittlern ignoriert werden, da es nicht auf eine gespeicherte Antwort anwendbar ist.
3.5. If-Range
Das If-Range Header-Feld bietet einen speziellen bedingten Anfragemechanismus, der den If-Match und If-Unmodified-Since Header-Feldern ähnelt, aber den Empfänger anweist, das Range-Header-Feld zu ignorieren, wenn der Validator nicht übereinstimmt, was zur Übertragung der neuen ausgewählten Darstellung anstelle einer 412 (Precondition Failed) Antwort führt. If-Range ist in Abschnitt 3.2 von [RFC7233] definiert.