Description
Link to problem area: https://spec.matrix.org/v1.10/server-server-api/#authentication
Issue
The spec mentions that:
The format of the Authorization header is given in RFC 7235.
In summary, the header begins with authorization scheme
X-Matrix, followed by one or more spaces, followed by a comma-separated list of parameters written asname=valuepairs. The names are case insensitive and order does not matter. The values must be enclosed in quotes if they contain characters that are not allowed in tokens, as defined in RFC 7230; if a value is a valid token, it may or may not be enclosed in quotes. Quoted values may include backslash-escaped characters. When parsing the header, the recipient must unescape the characters. That is, a backslash-character pair is replaced by the character that follows the backslash.
This summary has missed out the detail that the comma-separated list of parameters may have optional whitespace (a space 0x20 or tab 0x09 specifically) around them. See this bit of RFC 7235:
Authorization = credentials
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
*( OWS "," [ OWS auth-param ] ) ] ) ]
OWS is defined by RFC 7230 as:
OWS = *( SP / HTAB )
; optional whitespace
This was called out as an issue for Synapse a few years ago: matrix-org/synapse#1350 and a recently-submitted PR to Synapse has been filed to fix it: element-hq/synapse#17145
But I fear that the initial reason for this being missed was that the summary did not include this detail.
The "For compatibility with older servers, the sender should..." section should also be updated to include the bullet point:
- do not include whitespace around the commas between name=value pairs.
Alternatively, we could update the spec to explicitly disallow whitespace around commas, which would match current implementations. But it would diverge from typical Authorization header behaviour, which may be confusing.