Conditional Requests sind HTTP-Anfragen mit Bedingungs-Headern, die der Server nur dann voll beantwortet, wenn eine Bedingung erfüllt ist. Sie sparen Bandbreite (Antwort nur bei Änderung) und verhindern verlorene Aktualisierungen (Schreibkonflikte). Spezifiziert in RFC 9110.
Die wichtigsten Bedingungs-Header
If-None-Match: mit ETag — bei GET/HEAD liefert der Server304 Not Modified, wenn der ETag übereinstimmt; bei schreibenden Methoden stattdessen412 Precondition Failed.If-Modified-Since: mit Last-Modified — 304, wenn die Ressource seit dem Datum unverändert ist.If-Match: führt eine Methode nur aus, wenn der ETag exakt übereinstimmt (Schutz vor verlorenen Updates bei PUT).If-Match: *bedeutet „nur wenn die Ressource existiert“.If-Unmodified-Since: Gegenstück auf Zeitbasis — nur ausführen, wenn seit dem Datum nicht geändert wurde.If-Range: erlaubt bei Range-Requests die Fortsetzung eines Downloads nur bei unverändertem Validator.
Wann ein 304 entsteht
Ein Cache, der eine stale Antwort hält, sendet den gespeicherten Validator als Bedingung an den Ursprungsserver. Stimmt er überein, antwortet der Server mit 304 Not Modified und neuen Metadaten — der Body wird nicht übertragen. Das ist das Herzstück effizienten HTTP-Cachings.
Preconditions und Konflikte
RFC 9110 definiert die Reihenfolge der Auswertung (If-Match vor If-Unmodified-Since, If-None-Match vor If-Modified-Since). Ein fehlgeschlagener If-Match bei einer Schreiboperation liefert 412 Precondition Failed — der Client erfährt so von einem parallelen Update, statt es still zu überschreiben. Auch HTTP/2 und HTTP/3 unterstützen Conditional Requests unverändert.
Verwandte Grundlagen: HTTP, ETag, Last-Modified, Cache-Busting.