Skip to main content

2.1.3. Binary-Wrapped HTTP Fields

2.1.3. Binary-Wrapped HTTP Fields​

If the value of the HTTP field in question is known by the application to cause problems with serialization, particularly with the combination of multiple values into a single line as discussed in Section 7.5.6, the signer SHOULD include the bs parameter in a component identifier to indicate that the values of the field need to be wrapped as binary structures before being combined.

If this parameter is included with a component identifier, the component value MUST be calculated using the following algorithm:

  1. Let the input be the ordered set of values for a field, in the order they appear in the message.

  2. Create an empty List for accumulating processed field values.

  3. For each field value in the set:

    3.1. Strip leading and trailing whitespace from the field value. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this would be a no-op in a compliant implementation.

    3.2. Remove any obsolete line folding within the line, and replace it with a single space (" "), as discussed in Section 5.2 of [HTTP/1.1]. Note that this behavior is specific to [HTTP/1.1] and does not apply to other versions of the HTTP specification.

    3.3. Encode the bytes of the resulting field value as a Byte Sequence. Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations.

    3.4. Add the Byte Sequence to the List accumulator.

  4. The intermediate result is a List of Byte Sequence values.

  5. Follow the strict serialization of a List as described in Section 4.1.1 of [STRUCTURED-FIELDS], and return this output.

For example, the following field with internal commas prevents the distinct field values from being safely combined:

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

In our example, the same field can be sent with a semantically different single value:

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

Both of these versions are treated differently by the application. However, if included in the signature base without parameters, the component value would be the same in both cases:

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

However, if the bs parameter is added, the two separate instances are encoded and serialized as follows:

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

For the single-instance field above, the encoding with the bs parameter is:

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

This component value is distinct from the multiple-instance field above, preventing a collision that could potentially be exploited.

Last updated on