13. Conditional Requests (Bedingte Anfragen)

Eine bedingte Anfrage ist eine HTTP-Anfrage, die ein oder mehrere Anfrage-Header-Felder enthält, die eine Vorbedingung angeben, die getestet werden soll, bevor die Anfragemethode auf die Zielressource angewendet wird. Abschnitt 13.2 definiert, wann Vorbedingungen ausgewertet werden und die Reihenfolge ihrer Priorität, wenn mehr als eine Vorbedingung vorhanden ist.

Bedingte GET-Anfragen sind der effizienteste Mechanismus für HTTP-Cache-Aktualisierungen [CACHING]. Bedingungen können auch auf zustandsändernde Methoden wie PUT und DELETE angewendet werden, um das "Lost Update"-Problem zu verhindern: Ein Client überschreibt versehentlich die Arbeit eines anderen Clients, der parallel gearbeitet hat.

13.1. Preconditions (Vorbedingungen)

Vorbedingungen werden normalerweise in Bezug auf einen Zustand der Zielressource als Ganzes (ihr aktueller Wertesatz) oder den in einer zuvor erhaltenen Darstellung beobachteten Zustand (ein Wert in diesem Satz) definiert. Wenn eine Ressource mehrere aktuelle Darstellungen hat, jede mit ihrem eigenen beobachtbaren Zustand, wird eine Vorbedingung annehmen, dass die Zuordnung jeder Anfrage zur ausgewählten Darstellung (Abschnitt 3.2) zeitlich konsistent ist. Unabhängig davon wird kein Schaden entstehen, wenn die Zuordnung inkonsistent ist oder der Server keine geeignete Darstellung auswählen kann, wenn die Vorbedingung als false ausgewertet wird.

Jede unten definierte Vorbedingung beinhaltet einen Vergleich zwischen einem Satz von Validatoren, die aus früheren Darstellungen der Zielressource erhalten wurden, und dem aktuellen Zustand der Validatoren für die ausgewählte Darstellung (Abschnitt 8.8). Daher bewerten diese Vorbedingungen, ob sich der Zustand der Zielressource seit einem vom Client bekannten bestimmten Zustand geändert hat. Die Auswirkung einer solchen Bewertung hängt von der Methodensemantik und der Wahl der Bedingung ab, wie in Abschnitt 13.2 definiert.

Andere Vorbedingungen, die von anderen Spezifikationen als Erweiterungsfelder definiert sind, können Bedingungen für alle Empfänger, den Zustand der Zielressource im Allgemeinen oder eine Gruppe von Ressourcen auferlegen. Beispielsweise kann das "If"-Header-Feld in WebDAV eine Anfrage von verschiedenen Aspekten mehrerer Ressourcen wie Sperren ([WEBDAV], Abschnitt 10.4) abhängig machen, wenn der Empfänger dieses Feld versteht und implementiert.

Die Erweiterbarkeit von Vorbedingungen ist nur möglich, wenn die Vorbedingung sicher ignoriert werden kann, wenn sie unbekannt ist (wie If-Modified-Since), wenn für einen bestimmten Anwendungsfall eine Bereitstellung angenommen werden kann oder wenn die Implementierung durch eine andere Eigenschaft der Zielressource signalisiert wird. Dies fördert einen Fokus auf gemeinsame Standards mit geteilter Bereitstellung.

13.1.1. If-Match

Das "If-Match"-Header-Feld macht die Anfragemethode davon abhängig, dass der empfangende Ursprungsserver mindestens eine aktuelle Darstellung der Zielressource hat, wenn der Feldwert "*" ist, oder eine aktuelle Darstellung der Zielressource hat, die ein Entity-Tag hat, das einem Mitglied der im Feldwert bereitgestellten Liste von Entity-Tags entspricht.

Ein Ursprungsserver MUSS die starke Vergleichsfunktion beim Vergleichen von Entity-Tags für If-Match verwenden (Abschnitt 8.8.3.2), da der Client beabsichtigt, dass diese Vorbedingung die Anwendung der Methode verhindert, wenn es eine Änderung an den Darstellungsdaten gegeben hat.

If-Match = "*" / #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 Benutzeragenten parallel auf derselben Ressource agieren können (d. h. um das "Lost Update"-Problem zu vermeiden). Im Allgemeinen kann es mit jeder Methode verwendet werden, die die Auswahl oder Änderung einer Darstellung beinhaltet, um die Anfrage abzubrechen, wenn das aktuelle Entity-Tag der ausgewählten Darstellung kein Mitglied im If-Match-Feldwert ist.

Wenn ein Ursprungsserver eine Anfrage erhält, die eine Darstellung auswählt, und diese Anfrage ein If-Match-Header-Feld enthält, MUSS der Ursprungsserver die If-Match-Bedingung gemäß Abschnitt 13.2 auswerten, bevor er die Methode ausführt.

Um ein empfangenes If-Match-Header-Feld auszuwerten:

1. Wenn der Feldwert "*" ist, ist die Bedingung wahr, wenn der Ursprungsserver eine aktuelle Darstellung für die Zielressource hat.

2. Wenn der Feldwert eine Liste von Entity-Tags ist, ist die Bedingung wahr, wenn eines der aufgelisteten Tags mit dem Entity-Tag der ausgewählten Darstellung übereinstimmt.

3. Andernfalls ist die Bedingung falsch.

Ein Ursprungsserver, der eine If-Match-Bedingung auswertet, DARF die angeforderte Methode NICHT ausführen, wenn die Bedingung als false ausgewertet wird. Stattdessen KANN der Ursprungsserver anzeigen, dass die bedingte Anfrage fehlgeschlagen ist, indem er mit einem 412 (Precondition Failed)-Statuscode antwortet.

Alternativ kann, wenn die Anfrage eine zustandsändernde Operation ist, die bereits auf der Zielressource erfolgreich gewesen zu sein scheint, ein Ursprungsserver mit einem 2xx (Successful)-Statuscode antworten (d. h. die Zustandsänderung ist bereits erfolgreich, weil der Zustand der Ressource bereits das war, was erwartet wurde), wenn eines oder mehrere Entity-Tags, die im If-Match-Feldwert aufgelistet sind, mit dem Entity-Tag der ausgewählten Darstellung übereinstimmen.

Ein Client, der später ein If-Match-Header-Feld bereitstellen wird, SOLLTE zunächst ein oder mehrere Entity-Tags in einer vorherigen Anfrage erhalten, typischerweise durch Erhalten einer Darstellung aus dem ETag-Header-Feld (Abschnitt 8.8.3) der Darstellung.

13.1.2. If-None-Match

Das "If-None-Match"-Header-Feld macht die Anfragemethode davon abhängig, dass der empfangende Ursprungsserver keine aktuelle Darstellung der Zielressource hat, wenn der Feldwert "*" ist, oder eine aktuelle Darstellung der Zielressource hat, die kein Entity-Tag hat, das mit einem der im Feldwert bereitgestellten übereinstimmt.

Ein Empfänger MUSS die schwache Vergleichsfunktion beim Vergleichen von Entity-Tags für If-None-Match verwenden (Abschnitt 8.8.3.2), da schwache Entity-Tags für die Cache-Validierung verwendet werden können, auch wenn es Änderungen an den Darstellungsdaten gegeben hat, die semantisch unbedeutend sind.

If-None-Match = "*" / #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 zwei Situationen verwendet:

1. Mit GET oder HEAD, um eine zwischengespeicherte Darstellung zu aktualisieren, die kein Entity-Tag hat. Wenn ein Ursprungsserver eine Anfrage für If-None-Match mit GET oder HEAD erhält, SOLLTE er sie gemäß Abschnitt 13.2 auswerten.

2. Mit anderen Methoden, um eine versehentliche Änderung einer vorhandenen Darstellung zu verhindern. Wenn eine Anfrage ohne Vorbedingung zu etwas anderem als der Erstellung oder Ersetzung einer Darstellung führen würde und der Server eine aktuelle Darstellung für diese Ressource hat, SOLLTE ein Client einen If-None-Match-Feldwert von "*" senden.

Wenn ein Ursprungsserver eine Anfrage erhält, die eine Darstellung auswählt, und diese Anfrage ein If-None-Match-Header-Feld enthält, MUSS der Ursprungsserver die If-None-Match-Bedingung gemäß Abschnitt 13.2 auswerten, bevor er die Methode ausführt.

Um ein empfangenes If-None-Match-Header-Feld auszuwerten:

1. Wenn der Feldwert "*" ist, ist die Bedingung falsch, wenn der Ursprungsserver eine aktuelle Darstellung für die Zielressource hat.

2. Wenn der Feldwert eine Liste von Entity-Tags ist, ist die Bedingung falsch, wenn eines der aufgelisteten Tags schwach mit (Abschnitt 8.8.3.2) dem Entity-Tag der ausgewählten Darstellung übereinstimmt.

3. Andernfalls ist die Bedingung wahr.

Ein Ursprungsserver, der eine If-None-Match-Bedingung auswertet:

• Wenn die Anfragemethode GET oder HEAD ist und die Bedingung als false ausgewertet wird, SOLLTE der Ursprungsserver eine 304 (Not Modified)-Antwort generieren.

• Wenn die Anfragemethode nicht GET oder HEAD ist und die Bedingung als false ausgewertet wird, MUSS der Ursprungsserver eine 412 (Precondition Failed)-Antwort generieren.

• Andernfalls (d. h. die Bedingung ist wahr) SOLLTE der Ursprungsserver die Anfrage normal verarbeiten.

13.1.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 aktueller ist als das im Feldwert angegebene Datum und die Uhrzeit.

If-Modified-Since = HTTP-date

Beispiel:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn ein Empfänger ein Ursprungsserver ist und If-Modified-Since ein Anfrage-Header-Feld bei einer GET- oder HEAD-Methode ist, SOLLTE der Empfänger eine 304 (Not Modified)-Antwort senden, wenn das Last-Modified-Datum der ausgewählten Darstellung früher als oder gleich dem im If-Modified-Since-Header-Feld angegebenen Datum ist, es sei denn, die Bewertung gemäß Abschnitt 13.2 würde zu einer anderen Antwort führen.

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 in diesem Fall als genauerer Ersatz für die Bedingung in If-Modified-Since betrachtet, und die beiden sind nur bedingt kompatibel, wenn sie unabhängig voneinander ausgewertet werden.

Ein Empfänger SOLLTE das If-Modified-Since-Header-Feld ignorieren, wenn das im Feldwert angegebene Datum ungültig oder in der Zukunft liegt.

13.1.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 als oder gleich dem im Feldwert angegebenen Datum ist.

If-Unmodified-Since = HTTP-date

Beispiel:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn ein Empfänger ein Ursprungsserver ist und If-Unmodified-Since ein Anfrage-Header-Feld bei einer Anfragemethode außer GET oder HEAD ist, SOLLTE der Empfänger die Anfrage normal verarbeiten, wenn das Last-Modified-Datum der ausgewählten Darstellung früher als oder gleich dem im If-Unmodified-Since-Header-Feld angegebenen Datum ist. Andernfalls SOLLTE der Empfänger eine 412 (Precondition Failed)-Antwort senden, es sei denn, die Bewertung gemäß Abschnitt 13.2 würde zu einer anderen Antwort führen.

Ein Empfänger MUSS If-Unmodified-Since ignorieren, wenn die Anfrage ein If-Match-Header-Feld enthält; die Bedingung in If-Match wird in diesem Fall als genauerer Ersatz für die Bedingung in If-Unmodified-Since betrachtet, und die beiden sind nur bedingt kompatibel, wenn sie unabhängig voneinander ausgewertet werden.

Ein Empfänger SOLLTE das If-Unmodified-Since-Header-Feld ignorieren, wenn das im Feldwert angegebene Datum ungültig oder in der Zukunft liegt.

13.1.5. If-Range

Das "If-Range"-Header-Feld bietet eine spezielle Bedingung für Range-Anfragen (Abschnitt 14): Wenn der bereitgestellte Validator mit dem aktuellen Validator für die ausgewählte Darstellung übereinstimmt, wird das Range-Header-Feld wie üblich verarbeitet und ein oder mehrere Teilinhalte zurückgegeben. Wenn der Validator nicht übereinstimmt, wird das Range-Header-Feld ignoriert und die vollständige ausgewählte Darstellung zurückgegeben.

If-Range = entity-tag / HTTP-date

Ein Client DARF ein If-Range-Header-Feld NICHT in einer Anfrage generieren, die kein Range-Header-Feld enthält.

Ein Server MUSS ein in einer Anfrage empfangenes If-Range-Header-Feld ignorieren, die kein Range-Header-Feld enthält.

Die Absicht von If-Range besteht darin, einem Client zu ermöglichen, eine zwischengespeicherte unvollständige Darstellung effizient zu aktualisieren, wenn sie veraltet ist. Wenn das If-Range-Header-Feld nicht vorhanden wäre, würde eine unvollständige zwischengespeicherte Darstellung den Client zwingen, sie zu revalidieren (mit einer bedingten Anfrage mit If-Match oder If-Unmodified-Since) und nur die fehlenden Teile anzufordern, wenn die Revalidierung zeigt, dass sie noch aktuell ist, oder die gesamte zwischengespeicherte Darstellung zu ersetzen. Das If-Range-Header-Feld ermöglicht es dem Client, diesen zusätzlichen Rundweg zu vermeiden, indem er entweder die aktuellen Teile oder eine vollständige Darstellung in einer einzigen Anfrage anfordert.

Ein Server wertet die If-Range-Bedingung unter Verwendung der starken Vergleichsfunktion aus (Abschnitt 8.8.3.2), wenn der Feldwert ein Entity-Tag ist. Wenn der Feldwert ein HTTP-Datum ist, vergleicht der Server es mit dem Last-Modified-Feldwert der ausgewählten Darstellung, wobei eine Übereinstimmung vorliegt, wenn die Zeitstempelwerte genau gleich sind.

Ein If-Range-Header-Feld SOLLTE nur mit entweder If-Unmodified-Since und einem Last-Modified-Datum oder If-Match und einem Entity-Tag verwendet werden, das stark übereinstimmt.

13.2. Evaluation of Preconditions (Auswertung von Vorbedingungen)

13.2.1. When to Evaluate (Wann auswerten)

Sofern die Definition einer Vorbedingung nichts anderes besagt, MUSS ein Server empfangene Anfragevorbedingungen auswerten, wenn er eine Anfrage erhält, die eine Darstellung auswählt, bevor er die Methode ausführt, da ihre Auswertung die Ausführung der Methode beeinflussen kann.

Eine Folge der Auswertung von Vorbedingungen vor der Ausführung der Methode ist, dass unterschiedliche Vorbedingungen, die nach dem Beginn der Methodenausführung empfangen werden, keinen Einfluss auf diese Ausführung oder ihre Antwortse semantik haben.

Diese Vorbedingungen können in verschiedenen Auswahlschritten ausgewertet werden. In der Praxis sind die Validatoren für die "ausgewählte Darstellung" oft verfügbar, bevor die Methode ausgeführt wird, sodass die Vorbedingungen vor dem Erstellen oder Ändern einer Darstellung ausgewertet werden können.

13.2.2. Precedence of Preconditions (Priorität von Vorbedingungen)

Wenn mehr als ein bedingtes Anfrage-Header-Feld in einer einzigen Anfrage vorhanden ist, wird die Reihenfolge, in der die Vorbedingungen angewendet werden, wichtig. In der Praxis werden die Felder, die auf den Zustand der Zielressource wirken, oft zusammen eingesetzt, wie If-Unmodified-Since zusammen mit If-Match oder If-Modified-Since zusammen mit If-None-Match. Es können jedoch inkonsistente Kombinationen von Vorbedingungsheaderfeldern vorhanden sein.

Ein Server MUSS empfangene Anfragevorbedingungen in der folgenden Reihenfolge auswerten:

1. Wenn der Empfänger der Ursprungsserver ist und If-Match vorhanden ist, die If-Match-Vorbedingung auswerten und mit einem 412 (Precondition Failed)-Statuscode antworten, wenn sie als false ausgewertet wird.

2. Wenn der Empfänger der Ursprungsserver ist, If-Match nicht vorhanden ist und If-Unmodified-Since vorhanden ist, die If-Unmodified-Since-Vorbedingung auswerten und mit einem 412 (Precondition Failed)-Statuscode antworten, wenn sie als false ausgewertet wird.

3. Wenn If-None-Match vorhanden ist, die If-None-Match-Vorbedingung auswerten und mit einem 304 (Not Modified)-Statuscode (für GET/HEAD) oder 412 (Precondition Failed)-Statuscode (für andere Methoden) antworten, wenn sie als false ausgewertet wird.

4. Wenn der Empfänger der Ursprungsserver ist, die Methode GET oder HEAD ist, If-None-Match nicht vorhanden ist und If-Modified-Since vorhanden ist, die If-Modified-Since-Vorbedingung auswerten und mit einem 304 (Not Modified)-Statuscode antworten, wenn sie als false ausgewertet wird.

5. Wenn die Methode GET ist, der Empfänger eine gültige Anfrage für ein Range-Header-Feld hat und If-Range vorhanden ist, das Range-Header-Feld verarbeiten, wenn der Validator mit dem aktuellen Validator für die ausgewählte Darstellung übereinstimmt; andernfalls das Range-Header-Feld ignorieren und mit einer 200 (OK)-Antwort und der vollständigen ausgewählten Darstellung antworten.

6. Andernfalls wurden alle Bedingungen erfüllt, also die angeforderte Aktion normal ausführen und eine entsprechende Antwort generieren.

Ein Server, der als Ergebnis der Verarbeitung einen der oben genannten Antwortstatuscodes generiert, SOLLTE eine Darstellung des Zustands der Zielressource in der Antwortnutzlast generieren, wenn die Herkunft der Anfrage nicht vertrauenswürdig ist.

Jede Erweiterung der If-Match- und If-Unmodified-Since-Header-Felder muss diesen Vorbedingungsauswertungsalgorithmus gleichwertig aktualisieren, um ein konsistentes Verhalten aufrechtzuerhalten.