Code change:
Note that the value for "key="c"" has been re-serialized according to the strict "member_value" algorithm. <ins> 2.1.3. If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in security-non-list, the signer MAY include the "bs" parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. If this parameter is included with a component identifier, the component value is calculated using the following algorithm: Let the input be the ordered set of values for a field For each field value in the set: Strip leading and trailing whitespace from each item in the list.  Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this will be a no-op in a compliant implementation. Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification. Encode the string as a Byte Sequence Add the Byte Sequence to a List accumulator The intermediate result is a List of Byte Sequence values Follow the strict serialization of a List as described in STRUCTURED-FIELDS and return this output For example, the following field with internal commas prevents the distinct field values from being safely combined: If included in the signature base without parameters, its value would be: This is problematic because the same component value is created with the semantically distinct single field: However, if the "bs" parameter is added, the value is encoded and serialized as follows: For the single-instance field above, the encoding with the "bs" parameter is: This component value is distinct from the multiple-instance field above. </ins> 2.2. In addition to HTTP fields, there are a number of different

Related discussion:
text: This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and