Résumé

  • Le RFC 9651 fait correspondre des octets à une structure HTTP déclarée; il ne leur attribue pas, à lui seul, un sens opérationnel.
  • Entre une analyse réussie et une action légitime doivent subsister la règle du champ, le contexte protégé, l’autorisation locale et la preuve de la transition.

Dans beaucoup de chaînes d’automatisation, le premier succès visible est celui du parseur. Il reçoit une valeur, reconnaît un dictionnaire ou un item, puis livre une structure propre au reste du programme. Ce succès est séduisant parce qu’il est mesurable. Pourtant, il ne répond à presque aucune des questions qui comptent lorsqu’un système s’apprête à modifier un état: qui a produit cette information, de quel droit, pour quelle cible, selon quelle version de règle, avec quelle conséquence durable?

Le RFC 9651 apporte une réponse exigeante à une question plus étroite. Il offre aux auteurs de champs HTTP des formes communes — List, Dictionary et Item — ainsi que des algorithmes de sérialisation et d’analyse stricts. Un champ qui adopte explicitement ce modèle n’a plus besoin d’inventer une grammaire voisine de toutes les autres. Les implémentations peuvent donc s’accorder sur la forme abstraite que représentent les octets reçus.

Cette économie de syntaxe ne vaut pas mandat. Le texte impose aux auteurs d’un nouveau champ de faire davantage que choisir un type. Ils doivent définir la sémantique de la valeur, ses contraintes supplémentaires et les conséquences de leur violation. Cette obligation est décisive. Elle signifie qu’un parseur général ne peut pas savoir ce que veut dire une clé, quelle plage est acceptable, si une extension est admise, ni si une valeur doit être ignorée, refusée ou prise en compte. La grammaire est commune; la règle qui agit est propre au champ.

Une analyse réussie ne prouve donc qu’une chose limitée: le contenu reçu correspond au modèle syntaxique déclaré, selon la version du parseur utilisée. Elle ne prouve pas l’identité de l’émetteur. Elle ne prouve pas que les intermédiaires ont préservé le champ. Elle ne prouve pas que l’émetteur pouvait présenter cette valeur. Elle ne prouve pas que cette valeur est applicable à la ressource visée. Elle ne prouve ni l’accord d’un principal, ni la permission d’une opération, ni l’écriture effective d’un changement.

Le RFC choisit volontairement une analyse stricte. Une entrée non conforme fait échouer l’opération entière; le destinataire n’est pas invité à la réparer selon sa propre tolérance. Cette discipline réduit les divergences entre implémentations. Mais un échec d’analyse ne dit rien, par lui-même, de l’intention ou de la vérité d’un acteur. Il dit seulement que la valeur reçue ne satisfait pas l’algorithme. Lorsqu’un même champ est complété par plusieurs composants, une erreur d’un seul peut d’ailleurs faire tomber l’ensemble.

Le second contrôle appartient à la définition du champ. Le registre IANA peut signaler qu’un nom de champ a le type «Dictionary», «List» ou «Item». Cette colonne n’est pas un registre de sens, encore moins un registre d’autorisation. Pour interpréter une valeur, le destinataire doit retrouver la spécification du champ, ses membres autorisés, les contraintes de contexte et la conduite prescrite. Un dictionnaire correctement formé peut rester sans effet parce que sa sémantique ne s’applique pas ici.

Le troisième contrôle porte sur le contexte. Le RFC 9651 avertit qu’une partie capable d’injecter de nouveaux champs HTTP peut modifier le sens d’un champ structuré, sans que l’analyse ne puisse systématiquement le révéler par un échec. Lorsqu’une information doit résister à cette menace, il faut une protection explicitement choisie. TLS protège une relation de transport; une signature peut couvrir des composants précis. Le RFC 9421 existe justement pour rendre cette couverture explicite. Aucun objet retourné par un parseur ne permet de déduire que le champ a été signé, ni quels autres éléments ont été couverts.

Le quatrième contrôle est la décision locale. L’application doit relier la valeur interprétée à un principal authentifié, à une cible, à une politique et à un état actuel. Une valeur peut être présente sans être une instruction. Elle peut être intelligible sans être pertinente. Elle peut être pertinente sans être autorisée. Elle peut être autorisée sans que la transaction finale réussisse. Confondre ces étapes transforme un détail de représentation en pouvoir invisible.

La compatibilité entre le RFC 8941 et le RFC 9651 montre pourquoi cette séparation reste nécessaire après une mise à jour. Un parseur plus récent peut accepter une forme qui était auparavant rejetée. Cela n’autorise pas automatiquement cette forme dans chaque définition de champ plus ancienne. La logique propre au champ doit encore refuser une date, un paramètre ou une extension qu’elle ne prévoit pas. Une évolution du parseur agrandit éventuellement l’espace syntaxique; elle ne confère aucune autorité supplémentaire à l’émetteur.

La lecture de Lu Heng aide à ne pas glisser du symbole vers l’exécution. Une représentation lisible est une couche; l’effet qui change réellement un système appartient à la décision de l’entité qui exécute la règle locale. Le format commun peut réduire l’ambiguïté. Il ne doit jamais être pris pour la décision elle-même.

Sources