La requête doit être conditionnelle.
Quand l’utiliser
Exiger If-Match lors des mises à jour pour éviter les écritures perdues.
Causes courantes et solutions
428 indique au client que le serveur n’accepte ici que des requêtes conditionnelles : envoyez If-Match avec le dernier ETag lu, afin que des modifications concurrentes ne puissent pas s’écraser silencieusement, le problème de la mise à jour perdue. Un client qui reçoit 428 doit récupérer la ressource avec un GET, prendre son en-tête ETag et renvoyer le PUT ou le PATCH avec If-Match. Si l’ETag est périmé entre-temps, la réponse sera 412.
En tant que concepteur d’API, ne l’exigez que là où les mises à jour perdues posent problème, et documentez-le, car la plupart des clients HTTP n’envoient jamais d’en-têtes conditionnels d’eux-mêmes. Renvoyez l’ETag actuel à chaque GET et à chaque écriture réussie. Les proxys ne génèrent pas de 428 ; il vient toujours de l’application. Assurez-vous que les CDN et la compression ne réécrivent pas les ETag, sinon If-Match ne correspondra jamais.
Erreur client (4xx)
Les codes 4xx sont des erreurs client : la requête elle-même est incorrecte, non autorisée ou vise quelque chose qui n’existe pas. Renvoyer la même requête ne servira à rien.
À quoi ça ressemble
HTTP/1.1 428 Precondition RequiredComment l’envoyer
| Node.js / Express | res.status(428).end() |
|---|---|
| Python / Flask | return '', 428 |
| nginx | return 428; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/