Résumé

  • RFC 9218 encode une urgence u de 0 à 7 et un indicateur booléen i pour les réponses utiles par fragments. Le champ end-to-end Priority porte la préférence initiale ; les trames HTTP/2 et HTTP/3 PRIORITY_UPDATE ne modifient que le saut courant.
  • Ces paramètres ne promettent ni ordre d’achèvement, ni capacité, ni CPU, ni stratégie de retransmission. Un champ Priority dans la réponse n’accuse même pas réception d’un traitement prioritaire.
  • Une exploitation sûre conserve les valeurs du client, de l’origine et de chaque intermédiaire, la règle de fusion, la portée client, les files, le flow control, les octets DATA, les pertes et le jalon utilisateur. Sans cette chaîne, corrélation et causalité restent confondues.

L’image, la police et la mesure d’audience

Au début du chargement d’un article, le navigateur découvre une police dans l’en-tête du document. L’image principale n’est choisie qu’après évaluation de sa source responsive. Une requête de mesure part encore plus tard, après exécution du script. La police bloque la lecture ; l’image déterminera la plus grande zone visible ; la mesure peut attendre. Leur classement change donc pendant que la connexion travaille déjà.

L’origine possède une autre information : la police est généralement en cache, tandis que l’image traverse un backend contraint. Le CDN en possède une troisième : plusieurs clients partagent son pool de connexions vers l’origine. Si chacun pouvait transformer « urgent » en droit absolu, le premier site à marquer tout en u=0 imposerait sa politique aux autres.

Le résultat visible ne tranche pas le différend. Une image terminée la première peut simplement être un hit de cache. Une police terminée avant l’image ne prouve pas que la mise à jour a été ignorée : ses données avaient peut-être déjà franchi la fenêtre de flow control. Le waterfall décrit l’arrivée ; il ne révèle pas la décision qui a ouvert chaque créneau d’envoi.

Deux dimensions modestes pour remplacer un arbre fragile

Le système de dépendances et de poids de l’ancien HTTP/2 demandait aux clients de décrire un arbre relatif complexe. Son déploiement et son interopérabilité sont restés limités. RFC 9218 choisit des valeurs absolues plus simples dans un Dictionary conforme aux Structured Fields.

u va de 0, l’urgence la plus forte, à 7, la plus faible ; une requête sans valeur prend 3. i vaut false par défaut et indique si une partie de la représentation produit déjà quelque chose d’utile. Deux images progressives peuvent bénéficier d’un partage ; un fichier qui n’est exploitable qu’une fois complet peut plutôt gagner à finir seul parmi ses pairs.

Le RFC recommande, lorsque c’est possible, de servir d’abord les urgences les plus fortes. À urgence égale, les réponses non incrémentales peuvent être achevées dans l’ordre des requêtes, tandis que les incrémentales peuvent partager le débit. Le texte ne crée pourtant aucun droit opposable. Deux demandes u=0 restent en conflit. La valeur ne contient ni quota ni identité, et le réseau ne crée pas de capacité parce qu’un bit a changé.

Le niveau 7 convient aux tâches de fond, par exemple une mise à jour logicielle. Il ne signifie pas « ne jamais livrer ». Une priorité stricte qui bloque entièrement des requêtes sur des connexions backend séparées peut ressembler à un stall et provoquer une fermeture. Accorder un progrès minimal à chaque flux protège la continuité locale.

Le champ traverse le chemin ; la trame corrige un seul saut

Le champ Priority peut figurer dans une requête ou une réponse. Son caractère end-to-end permet au jugement initial du client d’atteindre l’origine et à la préférence de l’origine d’accompagner une réponse mise en cache. Il conserve une sémantique à travers différentes versions de HTTP.

Mais une priorité change. Un prefetch de fond peut devenir essentiel après une navigation. PRIORITY_UPDATE permet alors au client d’envoyer une valeur complète au peer immédiat. HTTP/2 emploie le type 0x10. HTTP/3 distingue requêtes et push avec 0xF0700 et 0xF0701 sur le control stream du client.

Cette différence empêche de parler d’« une priorité » sans provenance. Un CDN peut préserver le header du navigateur vers l’origine tout en envoyant une autre trame sur son backend. Il peut aussi remplacer le header, modifiant ainsi ce que tous les destinataires suivants voient. Chaque assertion, transformation et sortie doit rester séparée.

Avec HTTP/3, une update peut même arriver avant le stream ciblé. Le serveur peut retenir la plus récente jusqu’à l’ouverture du stream, dans une limite locale. Conserver seulement la dernière réduit l’engagement de mémoire. La faculté d’émettre un signal n’autorise pas le client à imposer un historique illimité au serveur.

La réponse de l’origine n’est pas un reçu

Le client n’a pas toujours la meilleure connaissance du contenu. L’origine peut savoir qu’une police débloque toute l’interface ou qu’une image prétendument décorative porte le fait central de la page. Elle peut exprimer son avis dans un Priority de réponse.

L’intermédiaire peut fusionner les paramètres client et serveur, mais RFC 9218 ne définit pas d’algorithme universel. Une absence de paramètre dans la réponse signifie que l’origine ne souhaite pas modifier cette composante du client. Dans une requête, la même absence appelle la valeur par défaut. Une normalisation identique dans les deux sens détruirait donc de l’information.

Surtout, le client ne peut lire ni la présence ni l’absence du header de réponse comme l’accusé d’un ordonnancement. Le cache a peut-être déjà livré l’objet ; la règle d’équité peut l’emporter ; le transport peut bloquer le stream. Afficher « honored » à partir du seul header invente un état que le protocole ne fournit pas.

La population de comparaison change à chaque architecture

Le CDN peut coalescer plusieurs connexions clientes sur un backend, ou distribuer une seule connexion frontend entre plusieurs backends. L’ensemble des compétiteurs change donc à chaque saut. u=2 n’est pas un classement mondial ; c’est une information relative dans la file qui l’utilise effectivement.

Cette file a besoin d’une limite d’identité. Pour un backend HTTP/1.1, le RFC recommande de n’exploiter la priorité client que si elle peut être rattachée à un end client individuel, au moyen d’une session ou d’une authentification. La valeur u n’identifie personne. Dans une file multitenant anonyme, laisser un expéditeur monopoliser le débit par u=0 revient à transformer un hint en autorisation de consommation.

Une inégalité intentionnelle peut néanmoins être légitime : une classe payante reçoit plus de capacité, ou une connexion réservée aux mises à jour utilise un congestion controller de récupération. C’est une politique commerciale ou opérationnelle locale. Elle doit avoir un propriétaire, une mesure, un plafond et une possibilité de recours ; elle ne doit pas se cacher derrière le RFC.

Le transport n’abandonne pas son jugement

Après l’ordonnanceur HTTP, TCP ou QUIC décide encore ce qui est réalisable. Les fenêtres, la congestion, le pacing, la perte et la retransmission peuvent dominer le résultat. Un cache hit peu urgent peut battre un miss urgent. Un calcul backend peut retarder la création même de la réponse.

Dans HTTP/3, une implémentation peut hésiter entre retransmettre les données perdues d’un stream moins urgent et envoyer des données neuves d’un stream plus urgent. RFC 9218 n’impose pas de réponse générale. La bonne décision dépend de la récupération et de la valeur applicative connues à cet endroit.

La preuve causale doit donc relier les identifiants de connexion et de stream, les champs bruts, chaque update, les concurrents actifs, la version et les quanta de l’ordonnanceur, les fenêtres, la congestion, les octets DATA par intervalle, la perte, les retransmissions, le cache, le backend et le jalon de rendu visé.

Un registre et une bibliothèque ne prouvent pas une politique active

IANA enregistre u, i, le setting HTTP/2 0x9, la trame 0x10 et les valeurs HTTP/3. Ce travail évite les collisions de syntaxe. Il ne prouve pas qu’un peer de production a négocié, parsé, activé la réception ou relié les valeurs à un ordonnanceur.

nghttp2 montre les étapes : l’application signale l’abandon des anciennes priorités RFC 7540, active la réception de l’extension, transmet le header ou appelle la fonction d’update. Une API disponible n’est pas encore une décision d’allocation.

Une affirmation sérieuse de support comporte donc six preuves : négociation, parsing exact, provenance et fusion, état de file, allocation d’octets, résultat sous contention contrôlée. Le mot « support » doit se limiter au dernier maillon réellement observé.

La force du standard réside dans ce qu’il laisse local

Lu Heng décrit une Minimum Initial Specification : assez de structure commune pour coopérer, sans capturer les décisions futures. RFC 9218 s’en rapproche avec deux paramètres, un dictionnaire, un champ end-to-end et des trames propres à chaque version. Il ne centralise ni fairness, ni cache, ni topologie backend, ni stratégie de retransmission.

Localized Future Decision permet aux opérateurs de répondre à leurs propres ressources et clients, à condition de rendre leurs choix observables. Voluntary Adoption se prouve par une négociation et un comportement répété, pas par une case. Running-Code Primacy exige enfin la chaîne complète : assertion, transformation, règle, octets, résultat et retour arrière.

Sans cette chaîne, « urgent » reste une demande. Il ne possède jamais le prochain octet.

Sources