Aller au contenu principal

RFC 8941 - Valeurs de champs structurés pour HTTP (Structured Field Values for HTTP)

  • Statut: Proposed Standard
  • Publié: February 2021
  • Stream: IETF
  • Remplacé par: RFC9651
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce document décrit un ensemble de types de données et d'algorithmes associés, visant à rendre la définition et le traitement des champs d'en-tête (header) et de pied de page (trailer) HTTP plus simples et plus sûrs. Ces champs sont appelés « Structured Fields (champs structurés) », « Structured Headers (en-têtes structurés) » ou « Structured Trailers (pieds de page structurés) ». Il s'applique aux nouvelles spécifications de champs HTTP souhaitant utiliser une syntaxe générique plus stricte que les valeurs de champs HTTP traditionnelles.

Statut de ce mémo (Status of This Memo)​

Il s'agit d'un document sur la voie des standards Internet.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'une révision publique et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). Pour plus d'informations sur les standards Internet, voir la section 2 de la RFC 7841.

Des informations sur le statut actuel de ce document, les éventuels errata et la manière de fournir des commentaires sont disponibles à l'adresse https://www.rfc-editor.org/info/rfc8941.

Table des matières (Table of Contents)​

Annexes (Appendices)​

Référence rapide des concepts clés (Quick Reference)​

Trois types de données de niveau supérieur​

1. List (liste)          - séquence ordonnée d'éléments
2. Dictionary (dictionnaire) - map de paires clé-valeur
3. Item (élément)        - valeur unique

Six types de données de base​

1. Integer (entier)         - plage : -999 999 999 999 999 à 999 999 999 999 999
2. Decimal (décimal)        - jusqu'à 3 décimales
3. String (chaîne)          - texte entre guillemets doubles
4. Token (jeton)            - identifiant sans guillemets
5. Byte Sequence (séquence d'octets) - données binaires encodées en Base64
6. Boolean (booléen)        - ?1 (true) ou ?0 (false)

Exemples​

List (liste)​

Example-List: "foo", "bar", baz
Example-List: 1, 2, (a b c)

Dictionary (dictionnaire)​

Example-Dict: a=1, b=2
Example-Dict: key="value", flag

Item (élément)​

Example-Integer: 42
Example-String: "hello world"
Example-Token: application/json
Example-Boolean: ?1

Importance​

La RFC 8941 est une spécification centrale de l'infrastructure HTTP moderne, largement utilisée dans :

1. En-têtes HTTP/2 et HTTP/3​

  • De nombreux nouveaux en-têtes HTTP utilisent le format de champs structurés
  • Encodage binaire plus efficace

2. Client Hints (RFC 8942)​

Sec-CH-UA: "Chromium";v="93", " Not;A Brand";v="99"
Sec-CH-Viewport-Width: 1024
Sec-CH-DPR: 2

3. CDN et contrôle de cache​

CDN-Cache-Control: max-age=3600, s-maxage=7200

4. Fonctionnalités Web modernes​

  • Cross-Origin Resource Policy (CORP)
  • Cross-Origin Embedder Policy (COEP)
  • De nombreux en-têtes liés à la sécurité

Pourquoi les champs structurés sont-ils nécessaires ?​

Problèmes des en-têtes HTTP traditionnels​

# Différents champs utilisent des syntaxes différentes :
Cache-Control: max-age=3600, private
Accept: text/html, application/json;q=0.9
Link: <https://example.com>; rel="preload"

# Chaque champ nécessite un analyseur personnalisé
# Sujets aux erreurs, difficiles à maintenir

Avantages des champs structurés​

# Syntaxe et règles d'analyse unifiées
Structured-Header: a=1, b=2, c=(x y z)

# Avantages :
✓ Types de données standardisés
✓ Algorithmes d'analyse clairs
✓ Meilleure interopérabilité
✓ Prise en charge des optimisations futures (comme l'encodage binaire pour HTTP/3)

Principes de conception​

1. Rigueur intentionnelle​

  • Échec immédiat en cas d'erreur d'analyse, sans tentative de « correction »
  • Évite les ambiguïtés et les problèmes de sécurité
  • Favorise l'interopérabilité

2. Compatibilité ascendante​

  • Modèle de données abstrait séparé de la sérialisation
  • Possibilité de définir des sérialisations plus efficaces à l'avenir

3. Praticité en priorité​

  • Basé sur l'expérience pratique des champs HTTP existants
  • Équilibre entre expressivité et complexité

Exemple rapide​

Définir un nouvel en-tête structuré​

Supposons que nous voulions définir un en-tête "Example-Priorities" :

Définition de la spécification :
-----------
L'en-tête Example-Priorities est un Structured Field (champ structuré).
Sa valeur DOIT être un Dictionary (dictionnaire).
Les clés du dictionnaire sont des identifiants de ressources (token), les valeurs sont des priorités (integer).

Exemple :
-----
Example-Priorities: css=10, js=5, images=1

Analyse et utilisation​

// Exemple de pseudo-code
const header = "css=10, js=5, images=1";
const dict = parseDictionary(header);

console.log(dict.get('css'));    // 10
console.log(dict.get('js'));     // 5
console.log(dict.get('images')); // 1

Public cible​

  • Auteurs de spécifications HTTP : à utiliser lors de la définition de nouveaux en-têtes HTTP
  • Implémenteurs de navigateurs : pour implémenter les algorithmes d'analyse et de sérialisation
  • Développeurs CDN et proxy : pour traiter les en-têtes HTTP modernes
  • Développeurs Web : pour comprendre le format des en-têtes HTTP modernes
Dernière mise à jour le