2. Motivation for Replacing RFC 7540 Stream Priorities (Motivation pour remplacer les priorités de flux RFC 7540)
La priorité de flux RFC 7540 (voir Section 5.3 de [RFC7540]) est un système complexe où les clients signalent les dépendances et les poids des flux pour décrire un arbre déséquilibré. Il a souffert d'un déploiement limité et d'une interopérabilité et a été déprécié dans une révision de HTTP/2 [HTTP/2]. HTTP/2 conserve ces éléments de protocole afin de maintenir la compatibilité câblée (voir Section 5.3.2 de [HTTP/2]), ce qui signifie qu'ils peuvent toujours être utilisés même en présence d'une signalisation alternative, telle que le schéma décrit dans ce document.
De nombreuses implémentations de serveur RFC 7540 n'agissent pas sur les signaux de priorité HTTP/2.
La priorisation peut utiliser des informations que les serveurs ont sur les ressources ou l'ordre dans lequel les requêtes sont générées. Par exemple, un serveur, avec une connaissance de la structure d'un document HTML, pourrait vouloir prioriser la livraison d'images critiques pour l'expérience utilisateur par rapport à d'autres images. Avec RFC 7540, il est difficile pour les serveurs d'interpréter les signaux des clients pour la priorisation, car les mêmes conditions pourraient entraîner une signalisation très différente de différents clients. Ce document décrit une signalisation plus simple et plus contrainte, nécessitant moins d'interprétation et permettant moins de variation.
RFC 7540 ne définit pas de méthode qui peut être utilisée par un serveur pour fournir un signal de priorité aux intermédiaires.
La priorité de flux RFC 7540 est exprimée par rapport à d'autres requêtes partageant la même connexion en même temps. Il est difficile d'incorporer une telle conception dans des applications qui génèrent des requêtes sans savoir comment d'autres requêtes pourraient partager une connexion, ou dans des protocoles qui n'ont pas de garanties d'ordre fortes entre les flux, comme HTTP/3 [HTTP/3].
Des expériences issues de recherches indépendantes [MARX] ont montré que des schémas plus simples peuvent atteindre au moins des caractéristiques de performance équivalentes par rapport aux configurations RFC 7540 plus complexes observées en pratique, au moins pour le cas d'utilisation Web.
2.1. Disabling RFC 7540 Stream Priorities (Désactivation des priorités de flux RFC 7540)
Les problèmes et les idées exposés ci-dessus ont fourni la motivation pour une alternative à la priorité de flux RFC 7540 (voir Section 5.3 de [HTTP/2]).
Le paramètre HTTP/2 SETTINGS_NO_RFC7540_PRIORITIES est défini par ce document afin de permettre aux points de terminaison d'omettre ou d'ignorer les signaux de priorité HTTP/2 (voir Section 5.3.2 de [HTTP/2]), comme décrit ci-dessous. La valeur de SETTINGS_NO_RFC7540_PRIORITIES doit (MUST) être 0 ou 1. Toute valeur autre que 0 ou 1 doit (MUST) être traitée comme une erreur de connexion (voir Section 5.4.1 de [HTTP/2]) de type PROTOCOL_ERROR. La valeur initiale est 0.
Si les points de terminaison utilisent SETTINGS_NO_RFC7540_PRIORITIES, ils doivent (MUST) l'envoyer dans la première trame SETTINGS. Les expéditeurs ne doivent pas (MUST NOT) modifier la valeur SETTINGS_NO_RFC7540_PRIORITIES après la première trame SETTINGS. Les récepteurs qui détectent un changement peuvent (MAY) le traiter comme une erreur de connexion de type PROTOCOL_ERROR.
Les clients peuvent envoyer SETTINGS_NO_RFC7540_PRIORITIES avec une valeur de 1 pour indiquer qu'ils n'utilisent pas les signaux de priorité HTTP/2. La trame SETTINGS précède tout signal de priorité HTTP/2 envoyé par les clients, de sorte que les serveurs peuvent déterminer s'ils doivent allouer des ressources au traitement des signaux avant l'arrivée des signaux. Un serveur qui reçoit SETTINGS_NO_RFC7540_PRIORITIES avec une valeur de 1 doit (MUST) ignorer les signaux de priorité HTTP/2.
Les serveurs peuvent envoyer SETTINGS_NO_RFC7540_PRIORITIES avec une valeur de 1 pour indiquer qu'ils ignoreront les signaux de priorité HTTP/2 envoyés par les clients.
Les points de terminaison qui envoient SETTINGS_NO_RFC7540_PRIORITIES sont encouragés à utiliser des signaux de priorité alternatifs (par exemple, voir Section 5 ou Section 7.1), mais il n'y a aucune exigence d'utiliser un type de signal spécifique.
2.1.1. Advice when Using Extensible Priorities as the Alternative (Conseils lors de l'utilisation des priorités extensibles comme alternative)
Avant de recevoir une trame SETTINGS d'un serveur, un client ne sait pas si le serveur ignore les signaux de priorité HTTP/2. Par conséquent, jusqu'à ce que le client reçoive la trame SETTINGS du serveur, le client devrait (SHOULD) envoyer à la fois les signaux de priorité HTTP/2 et les signaux de ce schéma de priorisation (voir Sections 5 et 7.1).
Une fois que le client reçoit la première trame SETTINGS qui contient le paramètre SETTINGS_NO_RFC7540_PRIORITIES avec une valeur de 1, il devrait (SHOULD) arrêter d'envoyer les signaux de priorité HTTP/2. Cela évite d'envoyer des signaux redondants qui sont connus pour être ignorés.
De même, si le client reçoit SETTINGS_NO_RFC7540_PRIORITIES avec une valeur de 0 ou si le paramètre de paramètres était absent, il devrait (SHOULD) arrêter d'envoyer des trames PRIORITY_UPDATE (Section 7.1), car ces trames sont susceptibles d'être ignorées. Cependant, le client peut (MAY) continuer à envoyer le champ d'en-tête Priority (Section 5), car c'est un signal de bout en bout qui pourrait être utile aux nœuds derrière le serveur auquel le client est directement connecté.