Résumé

  • Le code 428 permet à un serveur d’origine de refuser une écriture dépourvue de la condition exigée ; la prudence du client devient ainsi une règle d’admission contrôlée par la ressource.
  • If-Match et une étiquette d’entité forte constituent le cas classique. Une absence de condition appelle 428 ; une condition fournie mais fausse conduit normalement à 412.
  • Le mécanisme ne verrouille ni ne fusionne les données. Il exige des validateurs fiables, une comparaison atomique avec l’écriture et une vraie réconciliation après conflit.

Le succès trompeur du dernier enregistrement

Deux personnes ouvrent la même fiche. Elles lisent toutes deux la version 7. La première apporte une correction et enregistre la version 8. La seconde, qui travaille encore à partir de la version 7, renvoie ensuite le document entier. Si le serveur ne regarde que l’autorisation et la forme de la requête, les deux réponses peuvent annoncer un succès. La première correction a néanmoins disparu.

Cette mise à jour perdue ne vient ni d’un paquet corrompu ni d’un acteur hostile. La seconde écriture a indiqué où placer les octets, mais pas l’état qui avait justifié son contenu. Une opération sûre doit pouvoir dire : « applique ceci seulement si la ressource est encore celle que j’ai examinée ».

HTTP disposait déjà des requêtes conditionnelles. Les validateurs sont souvent racontés comme une économie de cache : le client présente une étiquette, et 304 évite de renvoyer un corps inchangé. La même preuve peut pourtant protéger une mutation. Il manquait un mot précis pour l’origine qui refusait toute écriture ne présentant pas cette preuve.

Publié en avril 2012, le RFC 6585 a créé ce mot : 428 Precondition Required. Il signifie que le serveur d’origine exige une requête conditionnelle. Le texte donne comme usage typique la prévention de l’écrasement d’un état modifié par un tiers entre la lecture et le PUT du client.

Une option devenue politique d’entrée

Lorsqu’une lecture reçoit l’étiquette forte "v7", une écriture accompagnée de If-Match: "v7" déclare son point de départ. L’origine n’exécute la méthode que si la représentation sélectionnée possède encore cette étiquette. Si une autre action a produit "v8", la condition est fausse et la mutation ne doit pas avoir lieu.

Le changement apporté par 428 est institutionnel autant que syntaxique. Le client prudent pouvait déjà employer If-Match. Désormais, l’origine peut annoncer que l’absence de condition suffit à fermer la porte. L’exemple du RFC conseille d’essayer If-Match, et la réponse devrait expliquer comment soumettre de nouveau la requête avec succès.

Ce conseil n’impose pas un en-tête unique à tout Internet. If-Match: * affirme qu’une représentation doit exister. If-None-Match: * affirme au contraire qu’elle ne doit pas exister, ce qui protège une création concurrente. En l’absence d’étiquette, If-Unmodified-Since peut offrir une condition temporelle. Chaque ressource doit définir la preuve qu’elle accepte.

Le cœur de 428 est donc l’autorité de l’origine : celle qui détient l’état actuel peut exiger que l’auteur de l’écriture révèle l’état dont il est parti.

428 avant l’évaluation, 412 après

La frontière avec 412 Precondition Failed est nette. 428 répond à une question de politique : une condition était obligatoire, mais la requête n’en a pas apporté une qui convienne. La méthode avec effets n’est pas tentée.

412 répond à une question de vérité : la condition était présente, l’origine l’a évaluée et elle s’est révélée fausse. Le client a bien nommé son passé ; ce passé ne correspond plus au présent.

Cette distinction sert directement l’exploitation. Une hausse de 428 signale souvent un ancien client, une documentation incomplète ou un chemin qui retire les conditions. Une hausse de 412 peut refléter de longues sessions d’édition, une concurrence réelle ou des étiquettes trop instables. Les deux courbes ne racontent pas la même panne.

428 ne remplace pas non plus 409. Un conflit 409 peut porter sur une contrainte métier ou la structure actuelle de la ressource. 428 impose la preuve avant que l’origine ne risque d’écraser quoi que ce soit. Il ne correspond pas davantage au verrou 423 de WebDAV : aucune possession exclusive n’est créée.

Pourquoi l’égalité doit être forte

Le RFC 9110, qui porte aujourd’hui la sémantique HTTP, impose la comparaison forte pour If-Match. Une étiquette faible peut suffire à dire que deux représentations sont équivalentes pour un cache. Elle ne suffit pas lorsque l’intention du client est d’arrêter la méthode dès que les données de représentation ont changé.

La fabrication des validateurs devient ainsi un élément du contrat public. Une étiquette qui ne change pas avec l’état protégé laisse passer une écriture obsolète. Une étiquette qui change pour un ordre de propriétés sans importance provoque des conflits artificiels. Exiger If-Match sans publier d’étiquette forte utilisable transforme 428 en impasse.

Les dates n’ont pas la même précision. If-Unmodified-Since vise aussi les mises à jour perdues lorsque l’étiquette manque, mais RFC 9110 considère If-Match comme plus exact et ignore la condition de date si les deux champs sont présents. Granularité des horloges et règles d’horodatage limitent la preuve temporelle.

La comparaison doit toucher la validation finale

Les préconditions sont évaluées par l’origine après les contrôles ordinaires et immédiatement avant l’action de la méthode. Un intermédiaire ne doit pas décider si If-Match décrit l’état actuel d’une origine qu’il ne possède pas. Il transmet la requête.

Cette proximité doit survivre à l’intérieur du service. Si le programme vérifie l’étiquette, ferme la transaction, puis écrit plus tard, un concurrent peut modifier la donnée entre les deux étapes. La conversation HTTP paraît correcte, alors que l’implémentation réintroduit une course entre contrôle et usage.

Il faut une opération atomique de comparaison et d’action : colonne de version, compare-and-swap ou transaction équivalente. HTTP définit ce que promet l’échange ; il ne fournit pas l’atomicité de la base.

Le périmètre du validateur doit également correspondre au périmètre de l’effet. L’étiquette d’une page rendue ne protège pas nécessairement plusieurs enregistrements en arrière-plan. Une requête qui modifie un compte puis publie un message externe franchit encore une autre frontière. 428 n’agrège pas ces opérations en transaction distribuée.

Voir un conflit n’est pas le résoudre

Après un 412, un client peut commettre une faute subtile : récupérer uniquement une nouvelle étiquette, la coller sur son ancien document complet et recommencer. La condition devient vraie, mais la modification intermédiaire n’a jamais été comparée. L’écrasement silencieux revient sous une apparence conforme.

La reprise correcte consiste généralement à relire l’état, comparer l’intention en attente et choisir entre fusion, abandon ou remplacement explicite. Une opération par champ ou une modification commutative peut réduire la surface du conflit. Dans d’autres cas, un humain doit décider. 428 rend ce travail visible ; il ne le réalise pas.

Le client ne peut d’ailleurs compter sur le serveur pour réclamer toujours la condition. RFC 6585 rend ces codes facultatifs et avertit expressément qu’un client ne peut se fier à 428 pour prévenir les mises à jour perdues. Lorsque l’API offre un mécanisme conditionnel, le client soucieux de son résultat doit l’employer de lui-même.

Un refus qui ne doit pas devenir une copie en cache

Une réponse 428 ne doit jamais être stockée par un cache. Elle décrit l’inadmissibilité d’une tentative donnée, non une représentation réutilisable de la cible. Rejouer plus tard un ancien refus permettrait à un intermédiaire d’imposer une politique qui appartient à l’origine.

La réponse devrait être opératoire : indiquer le champ attendu, montrer comment obtenir un validateur actuel et rappeler qu’une nouvelle lecture peut exiger une réconciliation. Le simple libellé « précondition requise » ne suffit pas à un client qui découvre le contrat.

Le registre IANA maintient 428 sous le nom Precondition Required et renvoie au RFC 6585. Derrière ce nom court se trouve une idée durable : avant de remplacer le présent, une écriture doit déclarer le passé qui l’autorise.

Sources et limites

Le dossier probant réunit RFC 6585, RFC 9110 et le registre IANA. Ces textes établissent la sémantique, l’ordre d’évaluation et les limites explicites. Ils ne mesurent ni le déploiement actuel, ni les pertes économiques, ni le comportement de toutes les bibliothèques. 428 n’est ni un verrou, ni une fusion, ni une garantie d’exécution unique.