Aller au contenu principal

4. Priority Parameters (Paramètres de priorité)

Les informations de priorité sont une séquence de paires clé-valeur (Key-Value Pairs), offrant de la place pour de futures extensions. Chaque paire clé-valeur représente un paramètre de priorité (Priority Parameter).

Le champ d'en-tête HTTP Priority (Section 5) est un moyen de bout en bout de transmettre cet ensemble de paramètres de priorité lorsqu'une requête ou une réponse est émise. Après avoir envoyé une requête, un client peut changer sa vision de la priorité de la réponse (Section 6) en envoyant des trames PRIORITY_UPDATE spécifiques à la version HTTP telles que définies dans les Sections 7.1 et 7.2. Les trames transmettent les paramètres de priorité sur un seul saut uniquement.

Les intermédiaires (Intermediaries) peuvent consommer et produire des signaux de priorité dans une trame PRIORITY_UPDATE ou un champ d'en-tête Priority. Un intermédiaire qui ne transmet que le champ d'en-tête de requête Priority au prochain saut préserve le signal de bout en bout original du client ; voir Section 14. Un intermédiaire pourrait transmettre le champ d'en-tête Priority et envoyer en plus une trame PRIORITY_UPDATE. Cela aurait pour effet de préserver le signal de bout en bout du client original, tout en instruisant le prochain saut d'utiliser une priorité différente, selon les conseils de la Section 7. Un intermédiaire qui remplace ou ajoute un champ d'en-tête de requête Priority remplace le signal de bout en bout du client original, ce qui peut affecter la priorisation pour tous les destinataires ultérieurs de la requête.

Pour le champ d'en-tête Priority et la trame PRIORITY_UPDATE, l'ensemble des paramètres de priorité est encodé comme un Dictionary (dictionnaire) (voir Section 3.2 de [STRUCTURED-FIELDS]).

Ce document définit les paramètres de priorité urgency (u) et incremental (i). Lors de la réception d'une requête HTTP qui ne porte pas ces paramètres de priorité, un serveur devrait (SHOULD) agir comme si leurs valeurs par défaut avaient été spécifiées.

Un intermédiaire peut combiner les signaux des requêtes et des réponses qu'il transfère. Notez que l'omission des paramètres de priorité dans les réponses est gérée différemment de l'omission dans les requêtes ; voir Section 8.

Les récepteurs analysent le Dictionary comme décrit dans la Section 4.2 de [STRUCTURED-FIELDS]. Lorsque le Dictionary est analysé avec succès, ce document impose l'exigence supplémentaire que les paramètres de priorité inconnus, les paramètres de priorité avec des valeurs hors limites ou les valeurs de types inattendus doivent (MUST) être ignorés.

4.1. Urgency (Urgence)​

La valeur du paramètre urgency (u) est Integer (entier) (voir Section 3.3.1 de [STRUCTURED-FIELDS]), entre 0 et 7 inclus, par ordre décroissant de priorité. La valeur par défaut est 3.

Les points de terminaison utilisent ce paramètre pour communiquer leur vision de la préséance des réponses HTTP. La valeur choisie d'urgence peut être basée sur l'attente que les serveurs pourraient utiliser ces informations pour transmettre les réponses HTTP dans l'ordre de leur urgence. Plus la valeur est petite, plus la préséance est élevée.

L'exemple suivant montre une requête pour un fichier CSS avec l'urgence définie à 0 :

:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0

Un client qui récupère un document qui se compose probablement de plusieurs ressources HTTP (par exemple, HTML) devrait (SHOULD) attribuer le niveau d'urgence par défaut à la ressource principale. Cette convention permet aux serveurs d'affiner l'urgence en utilisant des connaissances spécifiques au site web (voir Section 8).

Le niveau d'urgence le plus bas (7) est réservé aux tâches en arrière-plan telles que la livraison de mises à jour logicielles. Ce niveau d'urgence ne devrait pas (SHOULD NOT) être utilisé pour récupérer des réponses qui ont un impact sur l'interaction utilisateur.

4.2. Incremental (Incrémental)​

La valeur du paramètre incremental (i) est Boolean (booléen) (voir Section 3.3.6 de [STRUCTURED-FIELDS]). Il indique si une réponse HTTP peut être traitée de manière incrémentale, c'est-à-dire fournir une sortie significative au fur et à mesure que les morceaux de la réponse arrivent.

La valeur par défaut du paramètre incremental est false (0).

Si un client effectue des requêtes concurrentes avec le paramètre incremental défini sur false, il n'y a aucun avantage à servir des réponses avec la même urgence de manière concurrente car le client ne va pas traiter ces réponses de manière incrémentale. Servir des réponses non incrémentales avec la même urgence une par une, dans l'ordre dans lequel ces requêtes ont été générées, est considéré comme la meilleure stratégie.

Si un client effectue des requêtes concurrentes avec le paramètre incremental défini sur true, servir des requêtes avec la même urgence de manière concurrente pourrait être bénéfique. Cela distribue la bande passante de connexion, ce qui signifie que les réponses prennent plus de temps à compléter. La livraison incrémentale est plus utile lorsque plusieurs réponses partielles pourraient fournir une certaine valeur aux clients avant qu'une réponse complète ne soit disponible.

L'exemple suivant montre une requête pour un fichier JPEG avec le paramètre urgency défini à 5 et le paramètre incremental défini sur true.

:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i

4.3. Defining New Priority Parameters (Définition de nouveaux paramètres de priorité)​

Lors de la tentative de définir de nouveaux paramètres de priorité, il faut faire attention à ce qu'ils n'interfèrent pas négativement avec la priorisation effectuée par les points de terminaison ou intermédiaires existants qui ne comprennent pas les paramètres de priorité nouvellement définis. Étant donné que les paramètres de priorité inconnus sont ignorés, les nouveaux paramètres de priorité ne devraient pas changer l'interprétation ou modifier les paramètres de priorité urgency (voir Section 4.1) ou incremental (voir Section 4.2) d'une manière qui n'est pas rétrocompatible ou sûre en cas de repli.

Par exemple, s'il est nécessaire de fournir plus de granularité que huit niveaux d'urgence, il serait possible de subdiviser la plage en utilisant un paramètre de priorité supplémentaire. Les implémentations qui ne reconnaissent pas le paramètre peuvent continuer en toute sécurité à utiliser les huit niveaux moins granulaires.

Alternativement, l'urgence peut être augmentée. Par exemple, un agent utilisateur graphique pourrait envoyer un paramètre de priorité visible pour indiquer si la ressource demandée se trouve dans la fenêtre d'affichage.

Les paramètres de priorité génériques sont préférés aux valeurs spécifiques au fournisseur, à l'application ou au déploiement. Si une valeur générique ne peut pas être convenue dans la communauté, le nom du paramètre devrait être correspondamment spécifique (par exemple, avec un préfixe qui identifie le fournisseur, l'application ou le déploiement).

4.3.1. Registration (Enregistrement)​

De nouveaux paramètres de priorité peuvent être définis en les enregistrant dans le registre « HTTP Priority ». Ce registre régit les clés (courtes chaînes textuelles) utilisées dans le Dictionary (voir Section 3.2 de [STRUCTURED-FIELDS]). Étant donné que chaque requête HTTP peut avoir des signaux de priorité associés, il est intéressant d'avoir des longueurs de clé courtes, en particulier des chaînes à un seul caractère. Afin d'encourager les extensions tout en évitant les conflits involontaires entre des valeurs de clé attrayantes, le registre « HTTP Priority » applique deux politiques d'enregistrement, selon la longueur de la clé.

  • Les demandes d'enregistrement pour les paramètres de priorité avec une longueur de clé de un utilisent la politique Specification Required (spécification requise), selon la Section 4.6 de [RFC8126].

  • Les demandes d'enregistrement pour les paramètres de priorité avec une longueur de clé supérieure à un utilisent la politique Expert Review (examen par des experts), selon la Section 4.5 de [RFC8126]. Un document de spécification est apprécié mais non requis.

Lors de l'examen des demandes d'enregistrement, le ou les experts désignés peuvent prendre en compte les conseils supplémentaires fournis dans la Section 4.3 mais ne peuvent pas les utiliser comme base de rejet.

Les demandes d'enregistrement devraient utiliser le modèle suivant :

Name (Nom) : [un nom pour le paramètre de priorité qui correspond à la clé du paramètre]

Description : [une description de la sémantique et de la valeur du paramètre de priorité]

Reference (Référence) : [vers une spécification définissant ce paramètre de priorité]

Consultez le registre à https://www.iana.org/assignments/http-priority pour plus de détails sur l'endroit où envoyer les demandes d'enregistrement.

Dernière mise à jour le