Die Anfrage muss bedingt sein.
Wann du ihn verwendest
Wenn bei Updates If-Match verlangt wird, um verlorene Schreibvorgänge zu vermeiden.
Häufige Ursachen und Lösungen
428 sagt dem Client, dass der Server hier nur bedingte Anfragen akzeptiert: Sende If-Match mit dem ETag, das du zuletzt gelesen hast, damit sich gleichzeitige Änderungen nicht stillschweigend gegenseitig überschreiben, das sogenannte Lost-Update-Problem. Ein Client, der 428 erhält, sollte die Ressource per GET holen, ihren ETag-Header übernehmen und den PUT oder PATCH mit If-Match erneut senden. Ist das ETag bis dahin veraltet, lautet die Antwort 412.
Verlange bedingte Anfragen als API-Designer nur dort, wo verlorene Updates eine Rolle spielen, und dokumentiere das, denn die meisten HTTP-Clients senden von sich aus nie bedingte Header. Gib bei jedem GET und jedem erfolgreichen Schreibvorgang das aktuelle ETag zurück. Proxys erzeugen nie 428; der Code kommt immer von der Anwendung. Stell sicher, dass CDNs und Kompression keine ETags umschreiben, sonst passt If-Match nie.
Client-Fehler (4xx)
4xx-Codes sind Client-Fehler: Die Anfrage selbst ist fehlerhaft, nicht autorisiert oder verweist auf etwas, das es nicht gibt. Dieselbe Anfrage erneut zu senden hilft nicht.
So sieht es aus
HTTP/1.1 428 Precondition RequiredSo sendest du ihn
| Node.js / Express | res.status(428).end() |
|---|---|
| Python / Flask | return '', 428 |
| nginx | return 428; |
So prüfst du ihn
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/