2.1.1. Sérialisation stricte des Structured Fields HTTP (Strict Serialization of HTTP Structured Fields)

2.1.1. Sérialisation stricte des Structured Fields HTTP

Si la valeur d'un champ HTTP est connue de l'application comme étant un type Structured Field (tel que défini dans [STRUCTURED-FIELDS] ou ses extensions ou mises à jour) et que le type attendu du Structured Field est connu, le signataire PEUT inclure le paramètre sf dans l'identifiant de composant. Si ce paramètre est inclus avec un identifiant de composant, la valeur du champ HTTP DOIT être sérialisée selon les règles de sérialisation formelle spécifiées à la Section 4 de [STRUCTURED-FIELDS] (ou la section de sérialisation formelle applicable de ses extensions ou mises à jour) pour le type du champ HTTP. Ce processus remplace notamment tout espace blanc interne facultatif par un seul caractère d'espace, entre autres transformations possibles de la valeur.

Si plusieurs valeurs de champ apparaissent dans un message, ces valeurs DOIVENT être fusionnées en une seule structure List ou Dictionary avant sérialisation.

Si l'application ne connaît pas le type du champ ou ne sait pas comment sérialiser ce type, l'usage de cet indicateur produira une erreur. Par conséquent, le signataire ne peut signer de façon fiable des champs avec cet indicateur que lorsque le système du vérificateur connaît aussi le type.

Par exemple, le champ Dictionary suivant est une sérialisation valide:

Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)

S'il est inclus dans la base de signature sans paramètres, sa valeur serait:

"example-dict": a=1, b=2;x=1;y=2, c=(a b c)

En revanche, si le paramètre sf est ajouté, la valeur est reserialisée ainsi:

"example-dict";sf: a=1, b=2;x=1;y=2, c=(a b c)

La chaîne résultante sert de valeur de composant; voir Section 2.1.