Résumé

  • La RFC 9218 fait de la priorité HTTP une suggestion parmi les entrées de l’ordonnanceur, sans garantie d’ordre de traitement, de transmission ou d’achèvement.
  • Une preuve solide relie le signal observé à chaque saut, la règle de fusion, l’état de l’ordonnanceur, l’allocation des octets et le résultat visible.

Imaginons une plateforme de diffusion partagée qui sert une page, une feuille de style critique et plusieurs images. Le navigateur marque la feuille avec u=0. Un tableau de bord voit le champ et affirme que la ressource critique a été protégée. Pourtant, le nœud de périphérie combine un signal de réponse émis par l’origine avec ses règles locales d’équité et de capacité. Une petite image finit d’abord, tandis que la feuille attend le calcul d’origine. Le champ existe, mais il ne prouve pas l’ordre annoncé.

Il s’agit d’un cas hypothétique, non d’un incident attribué à un fournisseur. Il distingue quatre faits : la préférence du client, le traitement éventuel d’un intermédiaire, l’avis de l’origine et la décision finale de l’ordonnanceur. Ces faits peuvent être liés sans être identiques.

La RFC 9218 définit un mécanisme extensible de priorité des réponses HTTP. Le champ Priority porte un signal de bout en bout. Les trames PRIORITY_UPDATE de HTTP/2 et HTTP/3 portent un signal initial ou révisé sur un seul saut. Une trace côté navigateur ne révèle donc pas nécessairement la valeur reçue par le dernier ordonnanceur.

Les paramètres initiaux restent volontairement simples. L’urgence u va de 0 à 7, une valeur plus petite indiquant une préséance plus forte; la valeur par défaut est 3. Le booléen incrémental i indique si des fragments partiels produisent déjà un résultat utile; sa valeur par défaut est fausse. Ce vocabulaire exprime un point de vue, pas un algorithme universel de file ou de partage.

La norme pose une limite explicite : les signaux sont des suggestions et ne garantissent aucun ordre précis de traitement ou de transmission. L’ordonnancement dépend aussi de l’implémentation, de l’environnement, de la taille de l’objet, du cache, de la disponibilité de l’origine, de la congestion et du multiplexage. Même un serveur qui respecte l’urgence peut achever une réponse moins urgente avant une réponse plus grande et plus urgente.

L’ordre d’achèvement est ainsi un indicateur trompeur lorsqu’il est isolé. Une petite réponse peut finir vite tandis qu’une grande réponse prioritaire reçoit davantage de bande passante. Une réponse incrémentale peut partager la capacité afin que ses premiers fragments deviennent utiles. Premier octet, premier octet utile, fin du transfert et rendu sont quatre résultats différents.

La priorité peut changer après la requête. Un préchargement commencé en arrière-plan peut devenir urgent lors d’une navigation. Une trame PRIORITY_UPDATE transmet alors l’ensemble courant des paramètres et peut arriver avant l’ouverture du flux concerné. La preuve doit conserver l’ordre des champs et trames, leurs heures de réception et l’instant où l’ordonnanceur les a appliqués.

Les intermédiaires ajoutent leur propre frontière. Ils peuvent fusionner la priorité de la requête avec celle de la réponse, selon une politique laissée à l’implémentation. Lorsqu’ils regroupent plusieurs clients sur une connexion vers l’amont, une application absolue des u=0 peut retarder tous les autres. Une règle locale d’équité peut donc limiter la préférence sans violer la norme, tout en contredisant le pronostic simpliste d’un tableau de bord.

La RFC 9113 rappelle que l’ancien mécanisme de priorité de la RFC 7540 a été inégalement mis en œuvre et qu’il est désormais déconseillé dans HTTP/2. Une capture intitulée « priorité HTTP/2 » doit donc préciser le mécanisme, les paramètres négociés et le comportement de l’implémentation.

Un relevé opérationnel de l’effet de priorité doit joindre l’identité de la requête et de la réponse, les valeurs Priority, chaque PRIORITY_UPDATE avec son saut et son ordre, le résultat de fusion, la politique et les travaux concurrents, l’allocation d’octets, puis les temps jusqu’au premier octet, au premier octet exploitable, à l’achèvement et au rendu. Il doit aussi conserver l’état du cache, la taille, la disponibilité de l’origine et le partage de connexion. Ce relevé est une synthèse opérationnelle éditoriale, pas un objet de protocole IETF.

R066 reste ainsi séparé des sujets voisins. Add-Path demande si plusieurs routes couvrent des domaines de panne réellement indépendants. La RFC 8097 porte sur la provenance d’un état de validation d’origine. R065 portait sur l’autorité certifiée d’une origine sur une connexion. Ici, la question est : une préférence HTTP a-t-elle produit l’effet de livraison qu’on lui attribue ?

Sources