Résumé

  • La fraîcheur HTTP règle la réutilisation d’une réponse, pas une décision actuelle d’autorisation.
  • Une divulgation sensible exige une trace reliant l’état du cache à une autorisation de diffusion toujours en vigueur.

Imaginons qu’une origine retire un droit et rende indisponible une représentation sensible. Un cache partagé continue pourtant de servir la copie stockée jusqu’à la fin de sa durée de fraîcheur, et chaque réponse issue du cache est enregistrée comme une nouvelle approbation de l’origine. Le cache peut respecter ses métadonnées tandis que l’affirmation d’audit est fausse.

RFC 9111 calcule la fraîcheur à partir de l’âge, de la durée et des conditions de requête. Les réponses authentifiées ne peuvent être stockées que lorsque les directives le permettent. Ces règles gouvernent le cache; elles ne répètent pas la décision applicative concernant l’utilisateur actuel.

Une requête conditionnelle et un 304 Not Modified peuvent actualiser les métadonnées. Mais l’identité des octets ne prouve pas que la liste des destinataires autorisés est inchangée. L’invalidation après une méthode non sûre reste ciblée et ne garantit pas que chaque intermédiaire observe une modification de droit survenue ailleurs dans l’application. RFC 5861 distingue stale-while-revalidate, qui autorise une réponse périmée pendant une revalidation en arrière-plan, de stale-if-error, qui l’autorise lorsque l’obtention d’une réponse utilisable échoue.

Il faut donc une trace de décision de diffusion depuis le cache : clé et partition, date de stockage, âge calculé, durée de fraîcheur, requête et contexte d’autorisation pertinents, directives de réponse, validateur et résultat de revalidation, dérogation autorisant une réponse périmée, version de politique de l’origine, heure de livraison et composant ayant décidé de répondre.