Résumé

  • Dans draft-ietf-cdni-ci-triggers-rfc8007bis-20, le CDN aval doit répondre à la demande d’annulation, mais l’arrêt effectif reste optionnel à implémenter ; une tâche en attente peut démarrer et une tâche active peut finir avant que l’annulation ne l’emporte.
  • cancelling, cancelled, processed, complete et la suppression de la ressource sont des preuves différentes. Supprimer la ressource peut retirer le meilleur témoin alors que le travail demeure possible.

Une purge de cache possède deux horloges. La première mesure le temps nécessaire pour transmettre la commande. La seconde mesure le temps nécessaire pour que chaque nœud concerné ait réellement fini — ou ait réellement cessé d’agir. C’est dans l’écart entre les deux que naît le risque étudié par la révision 20 du projet CDNI Control Interface / Triggers.

Le document permet à un CDN amont de demander à un CDN aval de prépositionner, d’invalider ou de purger des métadonnées et du contenu. Prépositionner prépare une copie avant la demande. Invalider interdit de la réutiliser sans revalidation, mais ne l’efface pas nécessairement. Purger exige que les données visées ne soient plus conservées. Trois verbes proches en apparence produisent donc trois obligations opérationnelles différentes.

Une annulation qui peut arriver trop tard

La demande d’annulation est elle-même asynchrone. Le CDN aval doit répondre, mais le projet indique que l’annulation effective est facultative à implémenter. Même lorsqu’elle est acceptée, l’observation précédente peut déjà être périmée. Une ressource vue en état pending peut passer à l’exécution avant le traitement de la demande. Une ressource active ou processed devrait s’arrêter, mais elle peut atteindre sa fin normale entre-temps.

Le protocole ne masque pas cette course. Si l’arrêt n’est pas immédiat, l’état devient cancelling. Il ne devient cancelled que si le traitement cesse avant sa conclusion normale. Autrement, le résultat final peut être complete ou failed. La chronologie compte davantage que l’intention : avoir demandé l’arrêt à 14 h 00 ne prouve pas que la purge n’a pas touché une copie à 14 h 00 et une seconde.

Le périmètre temporel de la purge est lui aussi borné. Les données acquises avant l’entrée en état actif doivent être traitées ; les acquisitions déjà en cours devraient l’être. Les données acquises après le démarrage ne devraient pas l’être, mais le texte reconnaît que cette séparation n’est pas toujours réalisable. Le CDN amont ne peut donc pas déduire de la seule commande une coupure parfaitement nette de toute activité de cache.

Cette nuance devient concrète lors d’un remplacement. Si le nouveau contenu est prépositionné avant que l’ancienne purge ne soit terminée, il peut arriver d’abord puis être supprimé par la commande antérieure. Le mécanisme de dépendance proposé par l’extension de politique d’exécution n’est pas un embellissement : il sert à imposer l’ordre que l’intuition humaine suppose trop facilement.

Processed déclare une limite de visibilité

L’état le plus honnête du projet est peut-être processed. Il signifie que la ressource a été créée, qu’aucune mise à jour ultérieure ne sera fournie et que l’achèvement ne peut pas être confirmé par cette interface. Le CDN aval poursuit le travail et devrait fournir une estimation de fin, mais il ne promet pas le reçu final.

Il ne faut ni transformer cet état en succès, ni le traiter comme une panne. Il transfère une décision au CDN amont : l’action peut-elle rester ouverte sans preuve finale, et quelle observation indépendante permettra de la fermer ? Pour une purge, on peut rapprocher état terminal, objets signalés, sondes de cache, évolution des requêtes vers l’origine et observation de la représentation servie. Pour un prépositionnement, il faut contrôler la version réellement obtenue depuis l’empreinte visée.

Les codes HTTP se trouvent encore en amont de cette preuve. 201 Created atteste la création de la ressource de déclenchement. 202 Accepted indique qu’une modification ou une suppression a été admise mais n’est pas achevée. 204 No Content peut attester la disparition immédiate de la ressource d’état. Aucun de ces reçus ne décrit à lui seul le contenu encore présent dans les caches.

Supprimer la ressource, c’est aussi décider de la preuve

La suppression ressemble à l’annulation, sauf qu’elle rend ensuite la ressource indisponible. Le projet conseille donc d’annuler plutôt que de supprimer lorsqu’il faudra consulter le statut après coup.

Cette différence est plus grave qu’une préférence d’API. La suppression conserve la course : un traitement en attente peut commencer, et un traitement actif ou processed peut continuer jusqu’au bout. En parallèle, le chemin natif permettant de demander son état disparaît. L’opérateur peut ainsi perdre le témoin au moment même où il a le plus besoin de savoir quelle branche a réellement exécuté l’ordre.

L’expiration automatique pose le même problème à froid. Le CDN aval peut retirer les ressources terminales, puis répondre 404. Il doit publier le délai de conservation et ne devrait pas expirer une ressource processed tant qu’une exécution ou une redistribution peut raisonnablement continuer. L’identifiant unique évite qu’une nouvelle commande usurpe l’ancien URI ; il ne rend pas consultable une preuve déjà détruite.

Une cascade ne se termine pas au premier nœud rapide

Dans une interconnexion, un CDN de transit peut redistribuer la commande à plusieurs CDN aval. Il ne peut déclarer complete que lorsque l’exécution est terminée chez lui et dans toutes les branches concernées. Si une seule branche est processed, l’agrégat doit le rester. Une annulation reste cancelling jusqu’à ce que chaque branche ait atteint cancelled, complete ou failed.

Ce comportement protège contre une synthèse mensongère. La branche la plus rapide ne parle pas au nom de la plus lente. Il impose aussi une discipline documentaire : relier l’identifiant d’origine aux ressources de transit, conserver le chemin CDN, les erreurs par branche, les changements d’état et les observations du contenu après la transition.

Une topologie en losange complique encore l’histoire. Un même CDN aval peut recevoir des objets liés par plusieurs chemins, avec des délais et des métadonnées contradictoires ; le projet qualifie cette configuration d’erreur. Les compteurs étendus d’objets, de nœuds et d’octets peuvent révéler un résultat anormal, mais ils sont optionnels et peuvent compter plusieurs fois le même objet traité sur plusieurs nœuds. Ils aident à enquêter ; ils ne constituent pas un registre d’objets uniques.

Respecter la force exacte de complete

Le projet donne à complete une définition forte : toutes les opérations énumérées doivent avoir réussi, y compris celles des CDN aval en cascade. Cette garantie ne doit pas être minimisée.

Elle reste toutefois attachée à la demande effectivement formulée. Une purge qui ne correspond à aucun objet connu peut réussir avec zéro objet affecté. Une expression régulière peut décrire un ensemble différent de celui que l’opérateur avait en tête. Et l’interface de contrôle n’est ni l’interface de routage des requêtes, ni le journal de livraison, ni la preuve de la représentation reçue par l’utilisateur.

Une exploitation prudente conserve donc cinq reçus : commande d’origine, acceptation par le voisin, demande d’annulation ou de suppression, état terminal de chaque branche, puis observation indépendante de l’effet sur le contenu. Elle interdit de lancer une étape irréversible sur la seule foi de cancelling, de processed ou d’un code 2xx. Elle teste à l’avance les capacités d’annulation et de statut étendu de chaque partenaire.

La révision 20 reste un Internet-Draft. Le registre IANA figé affiche encore les types RFC 8007, pas les types v2 proposés, et les sources examinées ne prouvent aucun déploiement chez un CDN nommé. Le mérite du texte est ailleurs : il refuse qu’un accusé de réception confortable soit confondu avec la réalité distribuée qu’il ne peut pas encore prouver.

Sources