Résumé

  • Une réponse 304 Not Modified tranche une condition HTTP portant sur une représentation sélectionnée et permet de mettre à jour les métadonnées stockées ; elle ne certifie pas l’actualité de toute la chaîne de dépendances.
  • Pour une décision sensible, la preuve du validateur doit être reliée à la version des données, règles ou instantanés qui ont servi à produire la représentation.

Imaginons un point d’accès de configuration alimenté par un instantané de base de données. Le cache envoie If-None-Match avec l’étiquette d’entité qu’il possède. L’origine évalue cette condition pour la représentation sélectionnée et répond 304 Not Modified. Aucun nouveau contenu n’est transmis. Le cache actualise les métadonnées autorisées, puis un tableau de bord traduit ce signal vert en une affirmation beaucoup plus vaste : « chaîne de dépendances vérifiée ».

C’est là qu’une preuve de protocole devient une fiction de gestion. Le 304 peut être juste alors même que l’instantané utilisé par l’application est plus ancien que ne l’autorise la décision métier. HTTP a répondu précisément à la question posée ; le tableau de bord en a substitué une autre.

La condition porte sur un objet défini

La RFC 9110 définit If-None-Match par rapport aux étiquettes d’entité de la représentation sélectionnée. Pour un GET ou un HEAD conditionnel, une condition fausse conduit à un 304 au lieu du 200 qui aurait transporté le contenu. La valeur du mécanisme vient de cette portée limitée : le validateur a été évalué selon la sémantique HTTP.

Un 304 n’est donc pas un 200 vide. Il n’a pas de contenu, mais peut transmettre les champs utiles au cache, notamment ETag, Date, Cache-Control, Expires, Content-Location et Vary lorsque les règles l’exigent. La RFC 9111 explique ensuite comment le cache identifie les réponses stockées à actualiser. Les validateurs forts et faibles n’ont pas exactement le même rôle. Une fois la réponse correspondante trouvée, les champs d’en-tête applicables sont remplacés par ceux du 304, sous réserve des exclusions prévues.

Il s’agit d’une opération rigoureuse sur une représentation et ses métadonnées. Ce n’est pas une déclaration sur tous les systèmes ayant influencé cette représentation.

Validité de la représentation et actualité des dépendances

L’étiquette d’entité reflète la sémantique choisie par l’origine. Une application peut la calculer à partir des octets finaux, d’un numéro de version, d’un déploiement ou d’un autre élément propre à son implémentation. HTTP n’impose pas qu’elle encode la version de chaque ligne de base de données, ensemble de règles, indicateur de fonctionnalité, flux de droits ou résultat d’API utilisé en amont.

Pour une représentation dérivée, la différence est décisive. Les octets JSON peuvent être inchangés depuis leur mise en cache, rendant le 304 correct. Mais s’ils proviennent d’un instantané qui aurait dû être renouvelé cinq minutes plus tôt, la représentation inchangée conserve précisément l’obsolescence que l’opérateur cherche à détecter. La revalidation confirme la continuité à la frontière du validateur ; elle n’élargit pas cette frontière rétroactivement.

Les requêtes conditionnelles restent indispensables : elles économisent bande passante et calcul. Et tout 304 ne cache pas des données anciennes. La question est celle de la portée probante. « Cette représentation correspond encore à ce validateur » ne devient pas « toutes ses dépendances sont actuelles » sans une preuve complémentaire.

Conserver la filiation manquante

Pour une réponse de configuration importante, l’origine peut exposer ou journaliser un identifiant d’instantané, l’heure de mise à jour de la source, la version du paquet de règles ou un jalon de matérialisation. Le cache peut conserver la cible, l’identité de la réponse stockée, les champs conditionnels, les métadonnées du 304 et la décision exacte qui a consommé le résultat.

Le reçu de chaîne de validation proposé ici est une synthèse éditoriale de contrôle, et non un objet défini par l’IETF ou par les RFC citées. Il devrait réunir :

  • la cible de la requête et la représentation sélectionnée ;
  • le type et la valeur du validateur ainsi que les champs conditionnels ;
  • l’heure, le statut et les métadonnées de la réponse 304 ;
  • la réponse stockée et les champs mis à jour ;
  • les versions des instantanés, règles ou dépendances en amont ;
  • la décision ou l’automatisation qui s’est fondée sur le cache.

Si l’origine ne peut pas relier la représentation à une version de dépendance, l’état honnête est : « représentation revalidée ; actualité des dépendances inconnue ». Cette formule est plus étroite qu’un voyant vert, mais beaucoup plus exploitable.

Sources