The current RFCs are showing the parameters of a "header-field" to be separated by a semi-colon rather than a comma. This is most obvious looking at the structure of the "Accepts" header-field.
The need for this change is most obvious in the context of the Authorization header.. It is not uncommon to encounter use cases where multiple Authorization headers get created for a single message. As these messages pass through gateways, proxies, etc., there are instances where these multiple Authorization headers have been combined into a single multi-part header. Each "part" consists of {scheme parameters} where parameters are delimited by semi-colons. Having the "Signature" auth-scheme use a different, conflicting parameter delimiter will be a parsing issue for a number of platforms.
The current RFCs are showing the parameters of a "header-field" to be separated by a semi-colon rather than a comma. This is most obvious looking at the structure of the "Accepts" header-field.
The need for this change is most obvious in the context of the Authorization header.. It is not uncommon to encounter use cases where multiple Authorization headers get created for a single message. As these messages pass through gateways, proxies, etc., there are instances where these multiple Authorization headers have been combined into a single multi-part header. Each "part" consists of {scheme parameters} where parameters are delimited by semi-colons. Having the "Signature" auth-scheme use a different, conflicting parameter delimiter will be a parsing issue for a number of platforms.