Résumé

  • Dans l’interface CDNI Triggers v2 proposée, 201 Created atteste la création d’une ressource de déclenchement, pas l’achèvement d’une purge, d’une invalidation ou d’un prépositionnement.
  • Lorsqu’un CDN de transit a déjà accepté la demande amont, il doit convertir le rejet HTTP synchrone d’un CDN plus éloigné en description Error.v2 asynchrone. L’identité du CDN fautif peut rester masquée.
  • États, compteurs, annulation, réconciliation d’un nœud revenu en service et résultat côté lecteur exigent des preuves distinctes.

Un tableau de bord trop pressé

Le scénario tient en trois lettres. A demande à B de purger un contenu. B accepte, crée une ressource et renvoie 201 Created. La ligne passe au vert. B relaie ensuite la demande à C. C ne prend pas en charge un élément du déclencheur et répond 400 Bad Request.

Le vert n’était pas mensonger : une ressource a bien été créée chez B. Il répondait simplement à une question plus étroite que celle de l’exploitant, qui voulait savoir si le contenu avait disparu de toute la chaîne concernée.

Le projet CDNI Triggers v2, révision 20, daté du 2 septembre 2026, formalise précisément cette séparation. Le Datatracker de l’IETF le classe comme Internet-Draft actif du groupe CDNI, au stade « WG Document ». Il remplacerait la RFC 8007 s’il était approuvé. Ce n’est encore ni une RFC, ni une décision de l’IESG, ni une preuve de conformité ou de déploiement.

Par rapport à la révision 19, le texte développe fortement le traitement et la propagation des erreurs. La nouveauté éditoriale n’est donc pas la commande de purge elle-même, déjà présente dans la première édition, mais la transformation d’un refus après acceptation.

L’erreur change de véhicule

Si B détecte avant création une requête mal formée, un défaut de permission ou un type qu’il ne sait pas traiter, il répond en 4xx et ne crée aucune ressource. Après son acceptation, la transaction HTTP entre A et B est close. Le 4xx ou 5xx que C renvoie plus tard à B ne peut plus devenir rétroactivement la réponse HTTP reçue par A.

La révision 20 impose donc à B de traduire le rejet de C en objet Error.v2 Description placé dans sa propre ressource d’état. Un échec asynchrone survenu après acceptation chez C remonte par le même tableau d’erreurs. A ne découvre la panne qu’en interrogeant ensuite la ressource et en lisant l’état failed.

Le fait n’a pas disparu, mais sa nature probante a changé. Chez C, il s’agissait d’un rejet direct. Chez A, il devient une assertion rapportée par B. Une journalisation limitée au premier code HTTP manque l’échec ; une journalisation qui ne conserve que le code final perd la chaîne de transformation.

Le projet autorise en outre B à joindre le CDN Provider ID de C, sans l’y obliger. B peut utiliser son propre PID et masquer l’origine aval. Les registres de paramètres CDNI de l’IANA rendent le vocabulaire interopérable ; ils ne transforment pas une attribution facultative en transparence commerciale.

« Terminé » dépend de la topologie

Une nouvelle ressource commence normalement en pending, passe en active, puis finit en complete ou failed. Un CDN de transit ne peut annoncer complete qu’après achèvement chez lui et dans tous ses CDN aval. Si lui-même ou une branche annonce processed, il doit conserver ce même état vers l’amont.

Processed reconnaît une limite : la demande a été acceptée, mais le CDN ne donnera plus d’évolution d’état. Le convertir en réussite serait effacer l’incertitude que le protocole expose honnêtement.

Le projet recommande des identifiants uniques conformes à la RFC 9562, sans réutilisation de l’URI après suppression. Cette stabilité empêche de confondre deux ressources. Elle n’authentifie pas le résultat de l’action qu’elles représentent.

Même l’échec possède un calendrier. Lorsqu’une branche échoue, le transit attend la fin de ses traitements et de ceux de toutes les branches avant de publier failed. L’état terminal décrit donc la convergence du graphe déclaré, pas l’instant du premier incident ni le moment où un lecteur reçoit enfin le bon objet.

Une somme qui accepte les doublons

La révision 20 prévoit des compteurs cumulatifs d’objets, de nœuds et d’octets affectés. Elle recommande de les agréger sur les nœuds locaux et les CDN en cascade sans dédupliquer le même objet traité à plusieurs endroits. Leur fonction est de signaler une portée anormalement grande ou petite.

Un total de 10 000 ne signifie donc pas forcément 10 000 objets uniques. Un total nul n’est pas automatiquement un échec non plus : une purge ou une invalidation qui ne trouve aucun objet connu peut se terminer avec succès. Il faut préserver la définition du compteur, la règle de doublon, la cible attendue et une observation indépendante.

Annuler n’arrête pas le temps

Le CDN doit répondre à une demande d’annulation, mais l’exécution de l’annulation reste facultative. Entre la lecture de pending par A et le traitement de sa demande par B, le déclencheur peut passer en active. Un travail actif ou processed peut aussi se terminer avant l’arrêt. Cancelling est une étape, pas la preuve que les effets ont cessé.

La suppression retire la ressource d’état et conduit ensuite à 404 Not Found. C’est pourquoi le projet préfère l’annulation à la suppression lorsque l’amont veut encore consulter l’état terminal. Un 204 No Content prouve la disparition de la ressource de suivi, pas l’inversion d’une purge déjà exécutée.

La portée temporelle ajoute une autre course. La purge et l’invalidation couvrent les données acquises avant le passage en active et devraient viser les acquisitions déjà en cours. Elles ne devraient pas toucher les données acquises après le début, mais l’amont ne doit pas supposer que cette séparation est toujours réalisable. Prépositionner immédiatement un remplacement sans contrainte d’ordre peut conduire l’ancienne purge à supprimer le nouveau contenu.

La filiation documentaire éclaire cette limite. La RFC 6707 pose le problème de l’interconnexion, la RFC 7336 décrit les interfaces, la RFC 7337 fixe les exigences du contrôle, et la RFC 9110 fournit la sémantique HTTP. Aucun succès HTTP ne peut attester un événement extérieur à l’opération qu’il qualifie.

Le nœud absent revient dans le champ

L’indisponibilité temporaire d’un nœud du CDN aval est traitée comme une condition interne qui ne devrait pas, à elle seule, modifier l’état publié. Avant de reprendre son service normal, le nœud revenu doit être remis dans un état cohérent avec les déclencheurs antérieurs.

Cette abstraction protège l’interface, mais déplace la confiance vers la discipline de réconciliation du fournisseur. Un test utilisateur après le retour du nœud répond à une question que l’état terminal antérieur ne pouvait pas observer.

Les topologies en losange ajoutent un risque de métadonnées contradictoires lorsque plusieurs chemins propagent différemment. Le projet les traite comme une erreur de configuration et utilise les PID pour détecter les boucles. Cela ne garantit toujours pas que l’amont connaisse tous les acteurs de la chaîne.

Le protocole améliore le compte rendu. Il ne transforme pas le compte rendu en réalité complète.