1. Introduction
Il est courant que les représentations (Representations) d'une ressource HTTP [HTTP] aient des relations avec une ou plusieurs autres ressources. Les clients découvrent souvent ces relations lors du traitement d'une représentation récupérée, ce qui peut conduire à d'autres requêtes de récupération. Pendant ce temps, la nature des relations détermine si un client est bloqué pour continuer à traiter les ressources disponibles localement. Un exemple de ceci est le rendu visuel d'un document HTML, qui pourrait être bloqué par la récupération d'un fichier de feuilles de style en cascade (Cascading Style Sheets, CSS) auquel le document fait référence. En revanche, les images en ligne ne bloquent pas le rendu et sont dessinées progressivement au fur et à mesure que les morceaux des images arrivent.
HTTP/2 [HTTP/2] et HTTP/3 [HTTP/3] prennent en charge le multiplexage (Multiplexing) des requêtes et des réponses dans une seule connexion. Une caractéristique importante de toute implémentation d'un protocole qui fournit le multiplexage est la capacité de prioriser l'envoi d'informations. Par exemple, pour fournir une présentation significative d'un document HTML au plus tôt, il est important pour un serveur HTTP de prioriser les réponses HTTP, ou les morceaux de ces réponses HTTP, qu'il envoie à un client.
Les serveurs HTTP/2 et HTTP/3 peuvent planifier la transmission de données de réponse concurrentes par tout moyen qu'ils choisissent. Les serveurs peuvent ignorer les signaux de priorité (Priority Signals) des clients et toujours servir avec succès des réponses HTTP. Cependant, les serveurs qui fonctionnent sans savoir comment les clients émettent des requêtes et consomment des réponses peuvent causer des performances d'application client sous-optimales. Les signaux de priorité permettent aux clients de communiquer leur vision de la priorité des requêtes. Les serveurs ont leurs propres besoins qui sont indépendants des besoins des clients, ils combinent donc souvent les signaux de priorité avec d'autres informations disponibles afin d'informer la planification des données de réponse.
La priorité de flux (Stream Priority) RFC 7540 [RFC7540] permettait à un client d'envoyer une série de signaux de priorité qui communiquent au serveur un « arbre de priorité (Priority Tree) » ; la structure de cet arbre représente l'ordre relatif préféré du client et la distribution pondérée de la bande passante parmi les réponses HTTP. Les serveurs pouvaient utiliser ces signaux de priorité comme entrée dans les décisions de priorisation.
La conception et la mise en œuvre de la priorité de flux RFC 7540 ont été observées comme ayant des lacunes, comme expliqué dans la Section 2. HTTP/2 [HTTP/2] a par conséquent déprécié l'utilisation de ces signaux de priorité de flux. Le schéma de priorisation et les signaux de priorité définis dans ce document peuvent servir de substitut à la priorité de flux RFC 7540.
Ce document décrit un schéma extensible pour prioriser les réponses HTTP qui utilise des valeurs absolues. La Section 4 définit les paramètres de priorité (Priority Parameters), qui sont un format standardisé et extensible d'informations de priorité. La Section 5 définit le champ d'en-tête HTTP Priority (Priority HTTP Header Field), qui est un signal de priorité de bout en bout indépendant de la version du protocole. Les clients peuvent envoyer ce champ d'en-tête pour signaler leur vision de la façon dont les réponses doivent être priorisées. De même, les serveurs derrière un intermédiaire peuvent l'utiliser pour signaler la priorité à l'intermédiaire. Après avoir envoyé une requête, un client peut changer sa vision de la priorité de la réponse (voir Section 6) en envoyant des trames (Frames) spécifiques à la version HTTP telles que définies dans les Sections 7.1 et 7.2.
Les signaux de priorité du champ d'en-tête et de la trame sont des entrées dans le processus de priorisation des réponses d'un serveur. Ils ne sont qu'une suggestion et ne garantissent aucun ordre de traitement ou de transmission particulier pour une réponse par rapport à toute autre réponse. Les Sections 10 et 12 fournissent des considérations et des conseils sur la façon dont les serveurs pourraient agir sur les signaux.
1.1. Notational Conventions (Conventions de notation)
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
Ce document utilise la terminologie suivante de la Section 3 de [STRUCTURED-FIELDS] pour spécifier la syntaxe et l'analyse : « Boolean » (booléen), « Dictionary » (dictionnaire) et « Integer » (entier).
Les exemples de requêtes et de réponses HTTP utilisent le formatage de style HTTP/2 de [HTTP/2].
Ce document utilise l'encodage d'entiers de longueur variable (Variable-Length Integer Encoding) de [QUIC].
Le terme « control stream » (flux de contrôle) est utilisé pour décrire à la fois le flux HTTP/2 avec l'identifiant 0x0 et le flux de contrôle HTTP/3 ; voir Section 6.2.1 de [HTTP/3].
Le terme « HTTP/2 priority signal » (signal de priorité HTTP/2) est utilisé pour décrire les informations de priorité envoyées des clients aux serveurs dans les trames HTTP/2 ; voir Section 5.3.2 de [HTTP/2].