Résumé

  • digest-unsupported-algorithms permet à un serveur de signaler que les algorithmes proposés ne lui conviennent pas et, éventuellement, d’indiquer ceux qu’il préfère. C’est une information de capacité, pas une acceptation anticipée de la requête suivante.
  • Une nouvelle tentative doit conserver l’identité de l’opération, la portée du champ Digest et l’autorité de répétition. Changer d’algorithme ne prouve ni que la première tentative est restée sans effet, ni que la suivante sera admise.

La passerelle a reçu une réponse très structurée. Le type de problème annonçait digest-unsupported-algorithms. Le tableau unsupported_algorithms nommait le champ et l’algorithme refusé. Une préférence renvoyée dans la réponse indiquait deux algorithmes compris par le serveur. Le moteur d’automatisation a essayé le premier, puis le second, comme s’il parcourait une liste de portes déjà ouvertes.

Chaque tentative a franchi une étape supplémentaire. L’une a échoué sur l’autorisation, l’autre sur une règle métier. Le tableau de bord a pourtant résumé l’incident ainsi : « négociation d’intégrité en cours ».

Le problème ne venait pas du projet de norme. Il venait d’une promotion silencieuse : une liste de capacités était devenue un ordre de décision. Or le projet HTTP Problem Types for Digest Fields ne promet rien de tel. Il apporte une taxonomie d’erreurs pour que le client sache mieux ce qui a échoué. Il ne transforme pas la prise en charge d’un algorithme en garantie d’admission.

La révision étudiée est la 06, datée du 24 juin 2026 et expirant le 26 décembre 2026. Au 2 octobre 2026, Datatracker plaçait ce document du groupe HTTPAPI dans la file du RFC Editor, en attente d’un premier éditeur. Mike Bishop en était l’Area Director responsable ; l’examen IANA indiquait des actions nécessaires et un accusé RFC-Ed. Le texte vise le Standards Track comme Proposed Standard, mais aucun numéro RFC ne lui était encore attribué. Cet état montre un avancement documentaire, pas un déploiement ni une conformité de produit.

La compatibilité n’est que la première décision

Le type digest-unsupported-algorithms correspond à une situation précise : aucun algorithme fourni pour le champ examiné n’est pris en charge. Les entrées associent algorithm et header. La réponse peut aussi porter le champ de préférence correspondant pour montrer les algorithmes disponibles et leur ordre souhaité.

Cette précision est utile. Elle évite à un client de répéter exactement une option que le validateur ne comprend pas. Mais le serveur n’a encore attesté que sa capacité à traiter une famille de calcul. Il n’a pas promis que le condensat serait correct, que l’identité serait autorisée, que la ressource serait dans le bon état ou que l’opération respecterait les règles de l’application.

Une chaîne fiable distingue donc au moins quatre actes : choisir un algorithme compatible, construire la valeur sur la bonne portée, réussir la comparaison, puis obtenir une décision applicative. Le succès du premier acte ne préjuge pas des trois autres.

L’ordre de préférence ne change pas cette frontière. Une préférence facilite l’interopérabilité ; elle n’est pas un mandat général de nouvelle tentative. Elle ne dit pas non plus ce qui s’est produit pendant la requête précédente. Si une passerelle, un journal d’audit ou une application a créé un effet avant la réponse, la liste d’algorithmes ne l’efface pas.

Trois types, trois remèdes

Le projet recommande le statut 400 pour trois types de problème. Le type d’algorithme non pris en charge décrit la capacité du validateur. digest-invalid-values intervient lorsqu’une valeur ne peut pas avoir été produite par l’algorithme annoncé—par exemple une longueur impossible pour SHA-512. Il peut fournir un motif lisible par un humain. Réutiliser la même valeur inchangée a alors de fortes chances de reproduire la faute de calcul ou d’encodage.

Une erreur de syntaxe Structured Fields ne relève pas pour autant de ce type. Si le champ ne peut pas être analysé, le validateur ne dispose pas encore d’une paire algorithme-valeur utilisable. Mélanger syntaxe illisible et valeur mathématiquement impossible envoie l’incident au mauvais propriétaire.

digest-mismatched-values désigne encore autre chose : la valeur est exploitable, mais elle diffère de celle calculée par le serveur pour la portée indiquée. Les entrées donnent l’algorithme, le champ et le condensat fourni. Elles ne disent pas qui a modifié les octets. Le projet mentionne qu’un intermédiaire pourrait avoir provoqué une modification involontaire ; le conditionnel ne devient pas une attribution.

Ces distinctions ne sont pas décoratives. L’algorithme non pris en charge appelle une négociation. La valeur invalide appelle une correction du calcul ou de l’encodage. La divergence appelle une enquête sur la portée et le chemin. Aucune ne répond seule à la question métier : peut-on exécuter de nouveau l’opération ?

Le nom du champ conserve la couche de réalité

RFC 9530 sépare Content-Digest et Repr-Digest. Le premier porte sur le contenu HTTP ; le second sur la représentation sélectionnée. Les codages de contenu et les transformations font que ces domaines d’octets ne sont pas interchangeables. Le projet actif Unencoded-Digest propose encore une autre portée pour le contenu non encodé et n’est pas un RFC à la date de l’étude.

La présence de header dans chaque entrée est donc essentielle. Enregistrer seulement « SHA-256 accepté » retire la question qui donne son sens au résultat : SHA-256 sur quoi ? Une passerelle peut soutenir un algorithme tout en le calculant à une étape différente de celle attendue par le client ou l’origine.

Le risque est particulièrement élevé lorsque plusieurs champs apparaissent dans la même requête. Le projet autorise plusieurs diagnostics semblables. Le premier élément d’un tableau n’est pas nécessairement le problème principal, et l’ordre n’est pas une hiérarchie normative. Corriger la première ligne puis relancer automatiquement peut simplement révéler la deuxième.

Les extensions sont en outre facultatives. Leur absence n’a pas de signification spéciale. Un client ne peut pas conclure qu’un tableau absent signifie « aucun autre problème ». La couverture du diagnostic dépend de ce que le serveur choisit de divulguer, de sa mise en œuvre et des limites de sécurité.

Un détail de problème n’est pas un contrat de transaction

RFC 9457 fournit un format réutilisable pour les problèmes HTTP. Le type nomme une classe, les membres d’extension donnent du contexte. Le membre JSON status, lorsqu’il existe, reste indicatif et peut diverger du statut HTTP réellement reçu si un intermédiaire a modifié la réponse. Le corps n’annule pas la sémantique du protocole ni celle de l’application.

Cette séparation devient critique au moment de recommencer. RFC 9110 permet l’automatisation plus facilement pour les méthodes idempotentes. Pour une requête non idempotente, le client ne devrait recommencer automatiquement que s’il sait que la sémantique réelle est idempotente ou s’il peut déterminer que la première requête n’a jamais été appliquée. Un proxy ne doit pas recommencer automatiquement une requête non idempotente. Un client ne devrait pas relancer encore une tentative automatique qui a déjà échoué.

Le projet Digest emploie des exemples PUT et POST. Le type de problème n’ajoute pas une propriété d’idempotence à la méthode. Une clé d’idempotence, un identifiant de transaction, une condition ou un reçu durable peuvent donner l’autorité nécessaire. La préférence d’algorithme ne le peut pas.

Imaginez une création de paiement. La première tentative utilise un algorithme inconnu d’une passerelle, mais un composant en amont réserve déjà un identifiant. La seconde utilise l’algorithme préféré et atteint l’application. Sans identité stable, la succession des essais peut créer deux opérations ou laisser une réservation orpheline. Dire que « le serveur nous a proposé cet algorithme » ne résout aucune de ces issues.

La valeur calculée reste volontairement cachée

Pour une divergence, la réponse peut répéter le condensat fourni, mais le projet ne prévoit pas de communiquer la valeur calculée par le serveur. Cette retenue vise à éviter un oracle. Elle rappelle aussi que la réponse n’est pas un relevé complet de réconciliation.

Les détails peuvent révéler des choix d’implémentation, l’existence d’intermédiaires ou les algorithmes activés. Ils permettent une forme d’empreinte du serveur. Le condensat fourni, recopié dans le JSON, peut se retrouver dans des journaux, systèmes de tickets et outils d’analyse auxquels il n’était pas destiné. Une politique de collecte doit protéger la valeur brute et privilégier une empreinte sûre quand l’enquête n’exige pas davantage.

La précision opérationnelle a donc un coût de divulgation. Les serveurs peuvent choisir un problème plus général lorsque le risque dépasse le bénéfice. L’absence de détail qui en résulte ne doit jamais être transformée par le client en preuve négative.

Le minimum qui permet de décider

La discipline des couches de réalité de Heng Lu empêche la confusion. L’algorithme déclaré et le condensat sont des symboles portant sur des octets nommés. Le type de problème est l’assertion d’un validateur. La nouvelle requête est une action. L’admission, l’engagement de la transaction et le résultat utilisateur sont des observations ultérieures.

Une spécification initiale minimale devrait conserver l’identité de l’opération, la méthode et la cible, le numéro de tentative, la clé d’idempotence, le champ Digest, l’algorithme, une empreinte protégée de la valeur, le composant validateur, le statut reçu, le type de problème, les préférences proposées et le reçu applicatif. L’état inconnu ne doit pas être remplacé par « non exécuté » simplement parce qu’un statut 400 est arrivé.

Le code réel doit subir les cas difficiles : plusieurs champs, préférences dans des ordres variés, extensions omises, algorithme non pris en charge, longueur impossible, divergence valide, transformation intermédiaire et perte de réponse après engagement. Il faut aussi tester un POST avec et sans clé d’idempotence et vérifier que la deuxième relance automatique est stoppée.

Un serveur qui décrit ses capacités rend un service précieux au client. Il ne se porte pas garant de toute la trajectoire suivante. La bonne automatisation utilise la préférence pour reconstruire un message compatible, puis exige encore les preuves propres à chaque décision. Elle ne confond jamais « je sais calculer cet algorithme » avec « j’accepte cette opération ».

Sources