Code change:
type", "date", "etag") when using them as component identifiers. Unless overridden by additional parameters and rules, the HTTP field <del> value MUST be canonicalized with the following steps: </del> <ins> value MUST be canonicalized as a single combined value as defined in SEMANTICS. If the combined value is not available for a given header, the following algorithm will produce canonicalized results for an implementation: </ins> Create an ordered list of the field values of each instance of the field in the message, in the order that they occur (or will occur) in the message. Strip leading and trailing whitespace from each item in the list. <ins> 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 MESSAGING.  Note that this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. </ins> <del> Concatenate the list items together, with a single comma "","" and space "" "" between each item. </del> <ins> Concatenate the list of values together with a single comma (",") and a single space ("") between each item. </ins> The resulting string is the canonicalized component value. <ins> Following are non-normative examples of canonicalized values for header fields, given the following example HTTP message fragment: The following example shows canonicalized values for these example header fields, presented using the signature input string format discussed in create-sig-input: Since empty HTTP header fields are allowed, they are also able to be signed when present in a message.  The canonicalized value is the empty string.  This means that the following empty header: Is serialized by the create-sig-input with an empty string value following the colon and space added after the content identifier. Note: these are shown here using the line wrapping algorithm in RFC8792 due to limitations in the document format that strips trailing spaces from diagrams. </ins> 2.1.1. If value of the the HTTP field in question is a structured field <del> (RFC8941), the component identifier MAY include the "sf" parameter. If this parameter is included, the HTTP field value MUST be canonicalized using the rules specified in RFC8941.  For example, this process will replace any optional internal whitespace with a single space character. </del> <ins> (RFC8941), the component identifier MAY include the "sf" parameter to indicate it is a known structured field.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in RFC8941 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. </ins> <del> The resulting string is used as the component value in http-header. </del> <ins> For example, the following dictionary field is a valid serialization: </ins> <del> 2.1.2. </del> <ins> If included in the input string as-is, it would be: </ins> <del> Following are non-normative examples of canonicalized values for header fields, given the following example HTTP message: </del> <ins> However, if the "sf" parameter is added, the value is re-serialized as follows: </ins> <del> The following example shows canonicalized values for these example header fields, presented using the signature input string format discussed in create-sig-input: </del> <ins> The resulting string is used as the component value in http-header. </ins> <del> 2.1.3. </del> <ins> 2.1.2. </ins> An individual member in the value of a Dictionary Structured Field is identified by using the parameter "key" to indicate the member key as

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples