2.1.3. Champs HTTP encapsulés en binaire (Binary-Wrapped HTTP Fields)

2.1.3. Champs HTTP encapsulés en binaire

Si la valeur du champ HTTP concerné est connue de l'application comme posant des problèmes de sérialisation, en particulier pour la fusion de plusieurs valeurs en une seule ligne comme à la Section 7.5.6, le signataire DEVRAIT inclure le paramètre bs dans un identifiant de composant pour indiquer que les valeurs du champ doivent être encapsulées comme structures binaires avant fusion.

Si ce paramètre est inclus avec un identifiant de composant, la valeur de composant DOIT être calculée selon l'algorithme suivant:

1. Soit l'entrée l'ensemble ordonné des valeurs pour un champ, dans l'ordre où elles apparaissent dans le message.

2. Créer une List vide pour accumuler les valeurs de champ traitées.

3. Pour chaque valeur de champ dans l'ensemble:

   3.1. Supprimer les espaces en tête et en fin de la valeur de champ. Comme les valeurs de champ HTTP ne peuvent pas contenir d'espaces en tête ou en fin, ce serait une absence d'opération dans une implémentation conforme.

   3.2. Supprimer tout pli de ligne obsolète dans la ligne et le remplacer par un seul espace (" "), comme à la Section 5.2 de [HTTP/1.1]. Ce comportement est propre à [HTTP/1.1] et ne s'applique pas aux autres versions de la spécification HTTP.

   3.3. Encoder les octets de la valeur de champ résultante comme une Byte Sequence. La plupart des champs sont limités aux caractères ASCII, mais d'autres octets peuvent figurer dans la valeur dans certaines implémentations.

   3.4. Ajouter la Byte Sequence à l'accumulateur List.

4. Le résultat intermédiaire est une List de valeurs Byte Sequence.

5. Appliquer la sérialisation stricte d'une List comme à la Section 4.1.1 de [STRUCTURED-FIELDS], et renvoyer cette sortie.

Par exemple, le champ suivant avec des virgules internes empêche de fusionner sans risque les valeurs de champ distinctes:

Example-Header: value, with, lots Example-Header: of, commas

Dans notre exemple, le même champ peut être envoyé avec une seule valeur sémantiquement différente:

Example-Header: value, with, lots, of, commas

Ces deux versions sont traitées différemment par l'application. Cependant, si elles sont incluses dans la base de signature sans paramètres, la valeur de composant serait la même dans les deux cas:

"example-header": value, with, lots, of, commas

En revanche, si le paramètre bs est ajouté, les deux instances distinctes sont encodées et sérialisées ainsi:

"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHM=:, :b2YsIGNvbW1hcw==:

Pour le champ à instance unique ci-dessus, l'encodage avec le paramètre bs est:

"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHMsIG9mLCBjb21tYXM=:

Cette valeur de composant est distincte du champ multi-instances ci-dessus, ce qui évite une collision potentiellement exploitable.