6. Precedence (Priorität)

Wenn mehr als ein bedingtes Anfrage-Header-Feld in einer Anfrage vorhanden ist, wird die Reihenfolge, in der die Felder bewertet werden, wichtig. In der Praxis werden die in diesem Dokument definierten Felder konsistent in einer einzigen, logischen Reihenfolge implementiert, da "verlorene Aktualisierungs"-Vorbedingungen strengere Anforderungen haben als Cache-Validierung, und ein Entity-Tag als genauer als ein Datumswert angenommen wird.

Ein Empfänger-Cache oder Ursprungsserver MUSS die von dieser Spezifikation definierten Anfragevorbedingungen in der folgenden Reihenfolge bewerten:

1. Wenn der Empfänger der Ursprungsserver ist und If-Match vorhanden ist, bewerte die If-Match Vorbedingung:

   • wenn true, fahre mit Schritt 3 fort
   • wenn false, antworte mit 412 (Precondition Failed), es sei denn, es kann festgestellt werden, dass die zustandsändernde Anfrage bereits erfolgreich war (siehe Abschnitt 3.1)

2. Wenn der Empfänger der Ursprungsserver ist, If-Match nicht vorhanden ist und If-Unmodified-Since vorhanden ist, bewerte die If-Unmodified-Since Vorbedingung:

   • wenn true, fahre mit Schritt 3 fort
   • wenn false, antworte mit 412 (Precondition Failed), es sei denn, es kann festgestellt werden, dass die zustandsändernde Anfrage bereits erfolgreich war (siehe Abschnitt 3.4)

3. Wenn If-None-Match vorhanden ist, bewerte die If-None-Match Vorbedingung:

   • wenn true, fahre mit Schritt 5 fort
   • wenn false für GET/HEAD, antworte mit 304 (Not Modified)
   • wenn false für andere Methoden, antworte mit 412 (Precondition Failed)

4. Wenn die Methode GET oder HEAD ist, If-None-Match nicht vorhanden ist und If-Modified-Since vorhanden ist, bewerte die If-Modified-Since Vorbedingung:

   • wenn true, fahre mit Schritt 5 fort
   • wenn false, antworte mit 304 (Not Modified)

5. Wenn die Methode GET ist und sowohl Range als auch If-Range vorhanden sind, bewerte die If-Range Vorbedingung:

   • wenn true und die Range-Spezifikation auf die ausgewählte Darstellung anwendbar ist, antworte mit 206 (Partial Content) [RFC7233]
   • andernfalls ignoriere das Range-Header-Feld und antworte mit 200 (OK)

6. Andernfalls,

   • führe die angeforderte Methode aus und antworte entsprechend ihrem Erfolg oder Misserfolg.

Jede Erweiterung von HTTP, die zusätzliche bedingte Anfrage-Header-Felder definiert, sollte ihre eigene Bewertungsreihenfolge relativ zu den in diesem Dokument definierten bedingten Anfrage-Header-Feldern definieren. Die Erlaubnis für Erweiterungsfelder, die Priorität von Standard-Bedingungs-Header-Feldern neu zu definieren oder vom Bewertungsergebnis eines Standard-Feldes abhängig zu sein, würde zu mehrdeutigem oder inkonsistentem Verhalten führen.