Résumé

  • RFC 9842 permet de désigner une réponse HTTP comme dictionnaire externe pour de futures réponses, à condition que l’origine, le motif d’URL, la destination et la fraîcheur concordent.
  • Le dictionnaire disponible, le hachage annoncé par le client, le codage retenu par le serveur, le variant de cache et le sens de la réponse sont des faits distincts.

La compression par dictionnaire séduit parce qu’elle semble supprimer une étape. Une application déjà chargée possède des fragments utiles; le serveur peut alors envoyer une version plus courte d’une réponse ultérieure. Mais l’économie de bande passante ne supprime pas les responsabilités qui entourent cette seconde réponse. RFC 9842 est précieux précisément parce qu’il les maintient séparées.

Le premier acte appartient au serveur. Avec Use-As-Dictionary, il peut indiquer qu’une réponse est susceptible de servir de dictionnaire pour de futures requêtes. Le champ impose un motif de correspondance; celui-ci est limité à la même origine. Il peut aussi préciser une destination de requête, un identifiant et un type de dictionnaire. L’identifiant doit être traité comme opaque par le client, et le serveur ne peut pas s’en servir pour garantir le contenu du dictionnaire. Une étiquette de serveur n’est donc pas une attestation de bytes, encore moins une attestation de sens.

Le client doit ensuite vérifier son propre contexte. Le dictionnaire doit être frais, ou autorisé à être servi périmé. L’origine de la requête sortante doit correspondre. Sa destination et son URL doivent satisfaire les règles conservées. En présence de plusieurs dictionnaires, le RFC définit un ordre de préférence. Cela produit une décision de correspondance limitée: ce dictionnaire peut être proposé pour cette requête. Cela ne produit pas une réponse, ni une décision d’accès, ni une preuve qu’un contenu est encore exact dans le métier.

Si le client choisit de rendre cette capacité disponible, il envoie une seule valeur Available-Dictionary: le hachage SHA-256 du meilleur dictionnaire correspondant. Il peut alors proposer les codages dcb ou dcz dans Accept-Encoding. Cette suite est parfois racontée comme si le client détenait déjà la future réponse. En réalité, il détient une séquence de bytes conservée localement et offre au serveur une possibilité de compression. Il ne choisit ni la représentation que le serveur va émettre, ni la valeur sémantique de celle-ci, ni l’action qui pourra en résulter.

Le choix du serveur reste autonome. Il peut retourner une représentation non compressée ou choisir un autre codage. S’il reconnaît le codage offert et décide d’utiliser le dictionnaire annoncé, il répond avec Content-Encoding dcb ou dcz. Les deux formats lient le flux compressé au hachage du dictionnaire. Cette liaison est essentielle pour décoder sans ambiguïté. Elle ne garantit pas que le texte ou les données décodées sont actuels, autorisés, compris, approuvés ou exécutés.

Le cache ne comble pas cet écart. Une réponse compressée avec dictionnaire et susceptible d’être mise en cache doit varier selon Accept-Encoding et Available-Dictionary. Cette obligation évite qu’un client non compatible, ou muni d’un autre dictionnaire, reçoive le mauvais variant. Elle ne suffit pas à exprimer les conditions d’une décision commerciale, d’un droit d’utilisateur, d’une configuration changeante ou d’une action irréversible. La correction d’un variant HTTP et la validité d’un état métier restent deux contrôles différents.

Les précautions de sécurité renforcent la même lecture. Le mécanisme est réservé aux contextes sécurisés; le rapprochement dictionnaire-requête demeure de même origine; le client doit rejeter la réponse si les mitigations nécessaires échouent. RFC 9842 avertit également que la compression de données publiques et privées peut révéler de l’information par taille ou par temps. Il demande de traiter les hachages de dictionnaires comme un état sensible au suivi, à partitionner et à effacer comme les cookies. HTTPS et un hachage ne confèrent pas une autorisation.

Le lien compression-dictionary ne fait pas exception. Il peut signaler qu’un téléchargement futur serait utile. Le client reste libre du moment du téléchargement; la ressource récupérée doit encore contenir Use-As-Dictionary et des métadonnées de cache valables. Le lien n’établit ni réception, ni correspondance, ni emploi, ni résultat.

Pour un opérateur, le bon dossier relie sans les fusionner: ressource et hachage du dictionnaire, contrôle d’origine et de fraîcheur, annonce du client, sélection du serveur, clés de variation, décodage, sémantique de la réponse, décision et effet. RFC 9842 rend cette chaîne plus efficace. Il ne donne à aucune de ses mailles le pouvoir de parler au nom de toutes les autres.

Sources