Résumé

  • RFC 9111 permet de regrouper plusieurs défauts de cache en une requête transmise, à condition que la réponse puisse être réutilisée pour les requêtes concernées.
  • Chaque requête en attente conserve sa propre décision sur la cible, la méthode, les champs Vary, l’autorisation et l’état de contrôle du cache.

Imaginons une passerelle de périphérie, dans un cas explicitement hypothétique. Deux requêtes GET visant le même URI arrivent presque simultanément. La première est anonyme; la seconde contient un champ Authorization et attend une représentation liée à un compte. La passerelle choisit la première comme requête de référence, interroge l’origine une seule fois, puis distribue le 200 OK aux deux demandes. Elle économise un appel amont, mais fait disparaître la décision propre à la seconde requête.

RFC 9111 autorise le regroupement pour une raison pratique. Lors de défauts simultanés, un cache peut combiner les demandes en un seul appel transmis et réduire la charge de l’origine et du réseau. Cette permission est conditionnelle: la réponse retournée doit pouvoir être utilisée pour chacune des demandes concernées. Si elle ne convient pas à certaines, celles-ci doivent être transmises séparément, même au prix d’une latence supplémentaire.

La condition est décisive, car la ressemblance des URI ne suffit pas. Pour réutiliser une réponse stockée, l’URI cible doit correspondre, la méthode enregistrée doit autoriser la réutilisation, les champs de requête désignés par Vary doivent coïncider, les conditions no-cache doivent être satisfaites et la réponse doit être fraîche, autorisée à être périmée ou validée avec succès. Le regroupement réduit les appels amont; il ne supprime aucune de ces vérifications par requête.

Vary apporte une partie de la décision. RFC 9110 explique que ce champ nomme les éléments de la requête susceptibles d’avoir influencé la sélection de la représentation, ce qui élargit la clé de cache utilisée pour une correspondance ultérieure. RFC 9111 précise le rapprochement de ces champs, leur normalisation et le cas où ils sont absents. Une valeur Vary contenant * échoue toujours à correspondre. Vary n’unifie donc pas les demandes: il fournit au contraire des éléments pour les distinguer.

Authorization rend la frontière tangible. Selon RFC 9111, un cache partagé ne peut pas réutiliser une réponse à une requête contenant Authorization pour des demandes ultérieures, sauf si une directive Cache-Control l’autorise et si ses exigences sont respectées. Toutes les demandes regroupées ne sont pas nécessairement authentifiées; l’enseignement est que la distribution ne peut pas dépasser les contrôles applicables à une réutilisation ordinaire.

Il est donc dangereux de ne mesurer que les « appels origine économisés ». Une récupération réussie pour la requête de référence établit qu’une transaction amont a rendu une réponse. Elle ne prouve pas que chaque autre demande partage les mêmes champs de sélection, contraintes d’autorisation, règles de fraîcheur ou droits de réutilisation. Quand ces éléments diffèrent, transmettre séparément relève de la correction, non du gaspillage.

Un reçu de libération après regroupement peut préserver capacité et preuve. Il s’agit d’un dispositif de contrôle éditorial proposé ici, et non d’un objet défini par l’IETF. Le reçu relie la requête de référence à chaque demande en attente, conserve l’identité de la réponse, normalise méthode et cible, compare les champs Vary, évalue Authorization et Cache-Control, puis enregistre pour chaque demande une libération ou une transmission distincte.

La distinction devient vérifiable: le regroupement mutualise une récupération; la remise de la réponse reste une décision individuelle. L’opérateur peut alors compter le travail amont évité sans classer comme succès une diffusion qui n’était pas admissible.

Sources