Résumé

  • La collection filtrée Complete, facultative, rassemble des opérations réussies mais aussi des demandes processed qui ne feront plus l’objet de mises à jour. Son nom ne constitue pas un reçu de succès.
  • Le statut individuel complete suppose la réussite des actions concernées, y compris dans les réseaux situés plus loin dans une cascade. Une confirmation manquante ne peut pas être améliorée par le réseau intermédiaire.
  • L’heure estimée de fin aide à planifier, sans garantir le résultat. Cette interface n’impose pas de synchronisation des horloges entre CDNs.
  • Invalider, purger, précharger, annuler et supprimer un rapport ont des effets différents. Une décision ultérieure doit reposer sur la condition dont elle dépend réellement.
  • Le cas de remplacement décrit ici est un raisonnement opérationnel, pas le récit d’un défaut observé chez un fournisseur.

Le suivi est clos, la dépendance ne l’est pas

Le responsable d’un catalogue attend qu’un ancien contenu soit purgé avant de charger son remplaçant aux mêmes adresses. Son partenaire accepte la demande. Le rapport quitte ensuite les opérations actives et rejoint la collection Complete. Pour un tableau de suivi, la tâche semble avoir trouvé sa destination finale.

Ce responsable a pourtant besoin d’une autre réponse : le travail susceptible d’effacer le nouveau contenu est-il effectivement achevé ? Le classement d’un rapport ne suffit pas à répondre. Le statut individuel peut être processed, ce qui signifie que la demande a été acceptée et qu’aucune autre mise à jour ne sera fournie.

La différence n’est pas une subtilité de vocabulaire. Elle sépare la fin d’une promesse d’information de la réussite de l’action attendue. Si le lancement suivant dépend de cette action, clôturer le premier suivi ne clôture pas sa condition préalable.

Ce scénario est analytique. Il ne décrit ni une panne mesurée ni la pratique universelle des fournisseurs. Il met en lumière une possibilité explicitement prévue par RFC 8007, la spécification du contrôle CDNI par déclencheurs.

Une limitation qui doit rester visible

Publié en décembre 2016, RFC 8007 appartient à la catégorie Standards Track. Le registre du RFC Editor le classe Proposed Standard. Il décrit la partie de l’interface de contrôle permettant à un réseau amont de demander du travail à un réseau aval.

Il ne règle pas toute la relation commerciale entre réseaux. La découverte initiale de certains points d’accès, la configuration générale et les mécanismes locaux de contrôle d’accès ne deviennent pas une gestion mondiale uniforme parce qu’un déclencheur existe.

Le réseau aval conserve une collection de ressources de statut pour le réseau amont demandeur. Il peut proposer des vues filtrées. S’il les propose, il doit en communiquer les liens dans la collection générale ; ces vues ne sont pas obligatoires pour toute implémentation.

La vue appelée Complete réunit les tâches achevées avec succès et les demandes processed pour lesquelles il n’y aura plus de mises à jour. Le mot désigne donc une organisation du suivi, pas une assurance uniforme sur toutes les actions sous-jacentes.

Le statut individuel complete affirme que la commande s’est achevée avec succès. Processed indique au contraire que la demande a été acceptée et que le compte rendu n’évoluera plus, notamment lorsque l’achèvement ne peut pas être confirmé.

Ce second statut n’est pas un échec universel. Il ne prouve pas non plus une réussite, une absence de travail ou l’arrêt de tout effet futur. Il expose la limite de ce que le partenaire sait ou promet de rapporter. L’effacer sous une couleur commune transforme une limitation honnête en garantie implicite.

L’acceptation crée un moyen de suivre

Quand le réseau aval accepte un déclencheur, il crée une ressource de statut et en retourne l’adresse avec une réponse HTTP 201. Le demandeur dispose désormais d’une référence pour examiner la suite. L’opération demandée n’est pas pour autant devenue un fait accompli.

L’adresse doit être prise dans la réponse. Le réseau amont ne doit pas deviner sa structure ni déduire une relation imposée entre chemin et objet. Après suppression, une adresse de ressource de statut ne doit jamais être réutilisée. Cette règle protège l’identité de la demande contre une réattribution silencieuse.

Un partenaire qui suit le travail peut montrer une demande en attente, puis active, puis réussie ou échouée. S’il ne peut pas assurer ce suivi, il doit rendre cette limite explicite par processed et placer le rapport dans Complete. Il devrait fournir une estimation de fin adaptée à la planification.

Même une tâche sans action nouvelle peut rejoindre cette collection. Une demande de purge peut viser des données que le partenaire ne détient pas. Un préchargement peut porter sur des données déjà acquises et encore valides. Dans ces cas, processed ou complete peut être correct.

On ne peut donc pas convertir le nombre de rapports classés en quantité de données physiquement déplacées ou supprimées. Il faut lire ce qui a été demandé, le périmètre concerné et le résultat individuel, avant de décider ce qui peut raisonnablement suivre.

La cascade ne permet pas de fabriquer une meilleure réponse

Un réseau aval peut transmettre la distribution à d’autres réseaux. Les commandes doivent être propagées à ceux qui sont concernés. La réussite locale d’un intermédiaire n’efface pas la dépendance envers leur résultat.

RFC 8007 interdit de rapporter complete tant que la commande n’est pas complete dans tous les réseaux aval concernés. Si l’un d’eux rapporte processed, les intermédiaires doivent également rapporter processed, et non améliorer cette information en réussite confirmée.

La règle n’exige pas qu’un opérateur central commande chaque étape. Elle exige que la réponse agrégée conserve la portée de ce qu’elle affirme. Une cascade de rapports limités n’est pas une cascade de succès prouvés.

Des erreurs peuvent apparaître alors que la demande reste active pour d’autres adresses. Les descriptions identifient les URLs ou motifs concernés, et doivent reprendre exactement les références demandées sans les généraliser. Un échec partiel n’autorise pas à déclarer tout le périmètre échoué ; l’absence d’erreur reçue ne prouve pas davantage la réussite de chaque autre cible.

Cette granularité permet une continuation sélective. Un travail indépendant peut disposer d’une preuve suffisante, tandis qu’un remplacement dépendant attend une réponse différente. Ni l’arrêt général ni l’approbation générale ne correspondent nécessairement à la situation.

Les exigences CDNI de RFC 7337, document Informational, prévoyaient un retour approprié sur la réussite ou l’échec des actions, y compris en cascade. Le mécanisme de déclenchement conserve aussi la possibilité d’un suivi limité : c’est précisément cette possibilité qu’un lecteur de tableau doit reconnaître.

La bonne preuve dépend de l’action

Précharger demande l’acquisition de métadonnées ou de contenu. Invalider oblige à revalider les données avant une nouvelle utilisation, sans devoir les effacer. Purger demande qu’elles ne soient plus conservées une fois la commande exécutée, tout en permettant une acquisition ultérieure si elles sont nécessaires.

Les enregistrements IANA maintiennent ces distinctions. Parler seulement d’une tâche terminée masque le fait qu’une interdiction de réutilisation et une suppression de stockage sont deux résultats différents.

Une invalidation peut être complete alors que des serveurs de cache concernés sont hors ligne. Dans ce cas, ils ne doivent pas réutiliser les données sans les revalider après leur retour. La réussite porte sur cette règle de réutilisation, pas sur la preuve que chaque disque hors ligne a été vidé.

Une purge ou un préchargement peut être processed quand le travail se poursuivra au retour des caches. Si le partenaire abandonne l’action, il devrait signaler une erreur. Le comportement conforme ne peut pas être résumé par une équivalence entre tous les statuts terminaux et une suppression physique déjà réalisée.

Ces promesses concernent les données et la relation de distribution visées. Elles n’attestent pas l’effacement de toute copie sur Internet. Un compte rendu futur ne peut pas rappeler les octets déjà remis à un destinataire.

Envoyer dans l’ordre ne garantit pas l’exécution dans l’ordre

Le début et le rythme du travail restent sous le contrôle du réseau aval. Les commandes d’invalidation et de purge doivent s’appliquer aux données acquises avant l’acceptation. Elles ne devraient pas affecter les acquisitions ultérieures, mais le réseau amont ne peut pas compter sur une exclusion toujours réalisable.

Le partenaire peut aussi choisir comment traiter une acquisition déjà commencée lors de la réception de la commande. L’ordre des demandes sortantes n’est donc pas une frontière mondiale nette entre anciennes et nouvelles données.

RFC 8007 recommande d’attendre l’achèvement de la purge ou de l’invalidation avant d’engager un préchargement aux mêmes URLs. Sinon, les deux travaux peuvent se chevaucher : la nouvelle donnée est acquise, puis affectée par la commande encore en cours.

Une distribution en losange peut multiplier ce risque. Un même réseau peut recevoir le contenu et des commandes par plusieurs chemins amont légitimes. Les travaux répétés peuvent être planifiés séparément. Une branche a terminé sa purge et lance le préchargement pendant qu’une autre purge continue.

La possibilité de réacquérir le contenu limite certaines conséquences de disponibilité. Elle ne prouve pas que le premier lancement reposait sur un résultat unique et définitivement achevé pour toutes les commandes concurrentes.

Le responsable du remplacement doit donc préciser la condition qu’il accepte. Attend-il une réussite confirmée pour le périmètre nécessaire ? Accepte-t-il consciemment une estimation et son incertitude ? Le travail suivant est-il indépendant de la cible encore incertaine ? Le nom de la collection ne tranche aucun de ces choix.

L’heure estimée ne devient pas une attestation

La propriété facultative etime annonce quand le partenaire pense finir. Elle peut aider à établir un calendrier de préchargement. Elle ne certifie pas que le résultat attendu existe dès que cette heure passe.

Les heures de création, de modification et de fin estimée sont déterminées par le réseau aval. L’interface ne requiert pas de synchroniser les horloges des CDNs interconnectés. Classer leurs nombres dans un tableau ne suffit pas à reconstruire un ordre causal commun.

Un accord local peut prendre en compte les bases de temps et des marges opérationnelles. Cet accord ne change pas la définition de processed. Même avec des horloges parfaitement alignées, une estimation reste une estimation.

Les demandes conditionnelles permettent d’alléger l’observation. RFC 8007 recommande l’emploi d’ETags pour les ressources et collections. Les règles HTTP et leur modèle de cache expliquent cette économie.

Un rapport processed inchangé peut légitimement produire une réponse 304. Cela indique que sa représentation n’a pas changé, non que l’opération a finalement réussi. Interroger plus vite ne crée pas l’information que le partenaire a expressément cessé de promettre.

Annuler n’est pas remonter le temps

Le service doit répondre à une demande d’annulation, mais l’exécution effective de l’annulation est facultative. Une réponse peut indiquer une commande inactive, une annulation acceptée avec du travail toujours actif, ou une fonction non prise en charge.

Une tâche en attente peut démarrer avant le traitement de son annulation. Une tâche active peut ne pas s’arrêter immédiatement. Les effets déjà réalisés ne sont pas automatiquement inversés. Une commande complete ou failed ne doit pas être réétiquetée rétrospectivement comme annulée.

Les valeurs sur le réseau doivent aussi rester exactes. L’erratum technique vérifié 5053 corrige les chaînes en cancelling et cancelled ; 5054 corrige ecancelled. L’erratum éditorial 5064 explicite un exemple d’annulation distinct du nettoyage d’un rapport. Une traduction naturelle des explications ne doit pas modifier ces identifiants.

Supprimer la ressource retire le moyen de la consulter ainsi que ses références dans les collections. L’effet ressemble à l’annulation, mais ne constitue pas une restauration de ce qui a été purgé. Une consultation ultérieure en erreur ne révèle pas le résultat antérieur.

La rétention automatique impose une limite comparable. Sa durée annoncée doit être prise en compte. Conserver les rapports terminaux au moins vingt-quatre heures est recommandé, non obligatoire sans exception. Le demandeur devrait obtenir les résultats nécessaires avant que leur fenêtre de consultation se ferme.

La confiance transporte la réponse, pas la réussite

Les opérations doivent être limitées aux données du réseau amont concerné. Le cas en losange reconnaît plusieurs chemins d’acquisition légitimes ; il n’accorde pas une autorité générale sur les données d’autres clients.

Les collections sont propres au demandeur et ne doivent pas être accessibles aux autres CDNs. Le transport TLS avec authentification distante est requis, sauf protection alternative adaptée. Le contrôle d’accès demeure local, et l’arrangement commercial de confiance n’est pas défini par le protocole.

Les recommandations TLS actuelles remplacent les recommandations plus anciennes citées à l’origine. Une relation protégée peut aider à établir la provenance du compte rendu. Elle ne remplit pas les trous de son assurance opérationnelle.

Le cadre CDNI, les métadonnées et les journaux apportent des éléments complémentaires. Une observation de livraison réussie en un point n’atteste pas le résultat de toutes les actions dans tous les caches hors ligne ou descendants.

Sources

Les documents ci-dessous fondent les distinctions protocolaires. Les propositions de décision restent l’analyse de l’auteur.