2.1.1. Strict Serialization of HTTP Structured Fields

2.1.1. Strict Serialization of HTTP Structured Fields

If the value of an HTTP field is known by the application to be a Structured Field type (as defined in [STRUCTURED-FIELDS] or its extensions or updates) and the expected type of the Structured Field is known, the signer MAY include the sf parameter in the component identifier. If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the formal serialization rules specified in Section 4 of [STRUCTURED-FIELDS] (or the applicable formal serialization section of its extensions or updates) applicable to the type of the HTTP field. Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value.

If multiple field values occur within a message, these values MUST be combined into a single List or Dictionary structure before serialization.

If the application does not know the type of the field or does not know how to serialize the type of the field, the use of this flag will produce an error. As a consequence, the signer can only reliably sign fields using this flag when the verifier's system knows the type as well.

For example, the following Dictionary field is a valid serialization:

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

If included in the signature base without parameters, its value would be:

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

However, if the sf parameter is added, the value is reserialized as follows:

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

The resulting string is used as the component value; see Section 2.1.