Résumé

  • RFC 9111 impose au cache qui voit une réponse sans erreur à une requête non sûre d’invalider l’URI cible, mais uniquement dans les caches traversés par cette requête.
  • Une purge dite globale exige donc des preuves distinctes sur les chemins de cache, les URI associées et les clés dérivées propres à l’application.

Prenons un incident volontairement hypothétique. Un client envoie un PUT, l’origine répond 204 No Content et le tableau de contrôle affiche aussitôt « purge globale terminée ». L’écriture a traversé un cache applicatif et une passerelle régionale. Pourtant, un nœud de périphérie situé hors de ce chemin continue de servir une page de collection construite à partir de l’ancien objet. Le code 204 n’identifie ni ce nœud oublié ni la clé dérivée de la collection.

Ce résultat ne révèle pas une faiblesse du protocole. Il montre la frontière entre une règle HTTP et une affirmation d’exploitation. RFC 9110 qualifie une méthode de sûre lorsque sa sémantique est essentiellement en lecture seule; GET, HEAD, OPTIONS et TRACE le sont. Pour une méthode susceptible de modifier l’état, RFC 9111 impose au cache de transmettre la requête à l’origine: il ne peut pas fabriquer une réponse avant d’avoir relayé la requête et reçu la réponse correspondante.

Une obligation précise naît ensuite de la réponse. Si un cache reçoit une réponse sans erreur à une méthode non sûre, il doit invalider l’URI cible. Dans ce contexte, « sans erreur » signifie un statut 2xx ou 3xx. Invalider peut consister à supprimer les réponses stockées correspondantes ou à les marquer comme invalides, de sorte qu’une validation soit obligatoire avant toute réutilisation. La règle empêche une réutilisation aveugle; elle ne certifie pas la disparition de toutes les copies du système.

RFC 9111 autorise aussi l’invalidation d’autres URI. Les valeurs Location et Content-Location peuvent être candidates lorsqu’elles ont la même origine que l’URI cible. Cette faculté est utile, mais elle ne constitue pas un moteur universel de découverte des dépendances. Le cache ne doit pas déclencher cette invalidation pour une URI candidate d’une autre origine. Il n’est pas non plus tenu de deviner toutes les pages produit, listes, recherches, clés de substitution ou fragments précalculés dérivés par l’application.

La topologie impose une limite supplémentaire. Le texte précise que ce mécanisme ne garantit pas une invalidation globale: la requête de modification invalide les réponses dans les caches qu’elle traverse. Un cache présent seulement sur un autre chemin de lecture n’a reçu aucun événement protocolaire lui permettant d’exécuter cette obligation locale. Les architectures multi-CDN, les boucliers contournés et les chemins séparés pour API et pages transforment cette limite en enjeu de contrôle.

Trois affirmations sont trop souvent confondues. « L’origine a accepté l’écriture » décrit la réponse. « Un cache traversé a invalidé l’URI cible » décrit une action locale. « Tous les lecteurs verront désormais le nouvel état » concerne l’ensemble des routes, des identités de clés et des vérifications. La première ne prouve pas la deuxième à tous les niveaux; aucune ne suffit à établir la troisième.

Il faut donc un reçu du chemin d’invalidation. Il s’agit ici d’une synthèse de contrôle éditoriale, et non d’un objet défini par l’IETF. Ce reçu relie la requête non sûre et sa réponse aux caches qui l’ont transportée; consigne l’URI cible normalisée et l’action locale; sépare l’obligation sur la cible du traitement facultatif de Location ou Content-Location; rattache la carte applicative des collections, recherches, fragments et clés de substitution; puis conserve des sondes sans cache sur chaque chemin de service important.

Après une écriture réussie, la bonne question n’est donc pas « le 204 a-t-il purgé le monde? », mais « quel chemin a vu l’écriture, quel cache a agi, quelles identités ont été couvertes et quelles lectures indépendantes ont confirmé le nouvel état? » C’est ainsi qu’une action locale conforme au protocole devient une preuve crédible à l’échelle du système.

Sources