Aller au contenu principal

1. Introduction

La définition de la syntaxe des nouveaux champs d'en-tête (header) et de pied de page (trailer) HTTP est une tâche fastidieuse ; même avec les conseils de la section 8.3.1 de [RFC7231], de nombreuses décisions et pièges subsistent pour les auteurs potentiels de champs HTTP.

Une fois les champs définis, il est généralement nécessaire d'écrire des analyseurs (parsers) et des sérialiseurs personnalisés, car chaque valeur de champ traite une syntaxe apparemment commune de manière légèrement différente.

Ce document introduit un ensemble de structures de données communes pour la définition de nouvelles valeurs de champs HTTP, afin de résoudre ces problèmes. En particulier, il définit un modèle abstrait commun pour ces structures de données, ainsi qu'une sérialisation concrète pour exprimer ce modèle dans les champs d'en-tête et de pied de page HTTP [RFC7230].

Les champs HTTP définis comme « Structured Header (en-tête structuré) » ou « Structured Trailer (pied de page structuré) » (ou « Structured Field (champ structuré) » si le champ peut être l'un ou l'autre) utilisent les types définis dans cette spécification pour définir leur syntaxe et leurs règles de traitement de base, simplifiant ainsi le travail de définition pour les auteurs de spécifications et le travail de traitement pour les implémenteurs.

De plus, les futures versions de HTTP peuvent définir des sérialisations alternatives de ces modèles abstraits de structures, permettant aux champs utilisant ce modèle d'être transmis plus efficacement sans nécessiter de redéfinition.

Notez que l'objectif de ce document n'est pas de redéfinir la syntaxe des champs HTTP existants ; les mécanismes décrits ici s'appliquent uniquement aux champs qui choisissent explicitement de les utiliser.

La section 2 décrit comment spécifier des champs structurés.

La section 3 définit plusieurs types de données abstraits pouvant être utilisés dans les champs structurés.

Ces types abstraits peuvent être sérialisés en valeurs de champs HTTP ou analysés à partir de celles-ci en utilisant les algorithmes décrits à la section 4.

1.1 Traitement intentionnellement strict (Intentionally Strict Processing)​

Cette spécification définit intentionnellement un comportement d'analyse et de sérialisation strict à l'aide d'algorithmes pas à pas ; le seul traitement des erreurs défini est de faire échouer complètement l'opération.

Cette conception vise à encourager des implémentations fidèles et une bonne interopérabilité. Par conséquent, les implémentations qui tentent d'« aider » en étant plus tolérantes vis-à-vis des entrées dégradent en réalité l'interopérabilité, car elles exercent une pression sur les autres implémentations pour qu'elles mettent en œuvre des solutions de contournement similaires (mais potentiellement subtilement différentes).

En d'autres termes, le traitement strict est une caractéristique intentionnelle de cette spécification ; il permet de détecter et de corriger rapidement les entrées non conformes, et d'éviter les problèmes d'interopérabilité et de sécurité qui pourraient en résulter.

Notez qu'en raison de cette rigueur, si un champ est ajouté par plusieurs parties (par exemple, des proxys intermédiaires ou différents composants de l'expéditeur), une erreur dans la valeur de l'une des parties peut entraîner l'échec de l'analyse de la valeur entière du champ.

1.2 Conventions de notation (Notational Conventions)​

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] lorsqu'ils apparaissent en majuscules (comme indiqué ici).

Ce document utilise des algorithmes pour spécifier le comportement d'analyse et de sérialisation, et utilise la notation ABNF (Augmented Backus-Naur Form) de [RFC5234] pour illustrer la syntaxe attendue dans les champs d'en-tête HTTP. À cette fin, il utilise les règles VCHAR, SP, DIGIT, ALPHA et DQUOTE de [RFC5234]. Il inclut également les règles tchar et OWS de [RFC7230].

Lors de l'analyse à partir de champs HTTP, les implémentations DOIVENT (MUST) avoir un comportement indiscernable de celui qui suit les algorithmes. En cas de divergence entre l'algorithme d'analyse et l'ABNF, l'algorithme spécifié prévaut.

Pour la sérialisation vers des champs HTTP, l'ABNF illustre leur représentation filaire attendue, et les algorithmes définissent la manière recommandée de les produire. Les implémentations PEUVENT (MAY) s'écarter du comportement spécifié, à condition que la sortie puisse toujours être correctement traitée par les algorithmes d'analyse décrits à la section 4.2.

Points clés (Key Takeaways)​

1. Contexte du problème​

Les difficultés de la définition traditionnelle des champs HTTP :

# Chaque champ a sa propre syntaxe :
Cache-Control: max-age=3600, private
Accept: text/html, application/json;q=0.9
Content-Type: text/html; charset=utf-8
Link: <https://example.com>; rel="preload"

# Résultat :
- Chaque champ nécessite un analyseur personnalisé
- Des syntaxes apparemment similaires ont des différences subtiles
- Sujettes aux erreurs, difficiles à maintenir

2. La solution​

Les champs structurés fournissent :

  • ✅ Types de données unifiés : Integer, String, Boolean, List, Dictionary, etc.
  • ✅ Sérialisation standardisée : règles de format cohérentes
  • ✅ Algorithmes d'analyse clairs : élimination des ambiguïtés
  • ✅ Compatibilité ascendante : possibilité d'encodages plus efficaces à l'avenir

3. Philosophie de la rigueur​

❌ Mauvais exemple - analyseur tolérant :
Entrée : key="value   (guillemet fermant manquant)
Analyse tolérante : complète automatiquement le guillemet, analyse réussie

Problème :
- Différentes implémentations peuvent avoir des façons différentes de « corriger »
- Conduit à un comportement imprévisible
- Crée des failles de sécurité

✓ Bon exemple - analyseur strict :
Entrée : key="value   (guillemet fermant manquant)
Analyse stricte : échec immédiat, retourne une erreur

Avantages :
- Force les producteurs à générer un format correct
- Garantit un comportement cohérent entre toutes les implémentations
- Détecte les problèmes tôt

4. Objectifs de conception​

  • Ne pas redéfinir les champs existants : uniquement pour les nouveaux champs
  • Abstraction + concret : modèle abstrait + sérialisation HTTP/1.1
  • Extensible à l'avenir : possibilité de définir de nouvelles sérialisations pour HTTP/2, HTTP/3

5. Structure du document​

Section 2 : Comment définir des champs structurés → guide pour les auteurs de spécifications
Section 3 : Types de données abstraits → List, Dictionary, Item, etc.
Section 4 : Algorithmes de sérialisation et d'analyse → détails d'implémentation concrets

Impact pratique​

Pour les auteurs de spécifications​

Méthode traditionnelle :
---------
Définir un nouveau champ "Example-Field"
- Écrire une syntaxe ABNF personnalisée
- Détailler les règles d'analyse
- Gérer les cas limites
- Définir la gestion des erreurs
(peut nécessiter des dizaines de pages de documentation)

Méthode des champs structurés :
-------------
Définir un nouveau champ "Example-Field"
- Référencer la RFC 8941
- Indiquer qu'il s'agit d'un type Dictionary
- Définir la signification des clés et des valeurs
(peut ne nécessiter que quelques paragraphes)

Pour les implémenteurs​

// Méthode traditionnelle - chaque champ nécessite un analyseur personnalisé
function parseCacheControl(value) {
  // 50-100 lignes de code...
}
function parseAccept(value) {
  // Encore 50-100 lignes de code...
}
function parseContentType(value) {
  // Encore 50-100 lignes de code...
}

// Méthode des champs structurés - analyseur générique
const cacheControl = parseDictionary(header);  // réutilisable
const accept = parseList(header);             // réutilisable
const contentType = parseItem(header);        // réutilisable

Pour l'efficacité réseau​

HTTP/1.1 : format texte
Example-Dict: a=1, b=2, c=3

HTTP/2 (futur) : encodage binaire possible
[0x01] [dict] [3 items] [a:1] [b:2] [c:3]
↑ Plus compact, mais logiquement identique

Cas d'utilisation​

✓ Devrait utiliser les champs structurés​

  • Définir de nouveaux en-têtes HTTP
  • Nécessite des structures de données complexes (listes, dictionnaires)
  • Souhaite prendre en charge un encodage plus efficace à l'avenir
  • Recherche une bonne interopérabilité

✗ Ne devrait pas utiliser les champs structurés​

  • Champs existants déjà définis (comme Cache-Control)
  • Champs à valeur unique simple (possible, mais pas obligatoire)
  • Champs nécessitant une compatibilité ascendante avec les anciens clients
Dernière mise à jour le