You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The RFC7235 syntax forWWW-Authenticate and Authorization uses , (commas) to separate key-value pairs rather that semicolons as many other header fields and as suggested by RFC8941 for new header fields. This means that one has to be very careful when parsing concatenated WWW-Authenticate or Authorization headers. This was discussed in Clarify multiple authorization header behaviour or concatenation method issue on the http-core repo in Nov 2018. I am not 100% sure what the result of that discussion was.
We have potentially a few Authentication methods we would like to allow. At least: Basic, Bearer (for Solid-OIDC I guess, but the spec does not make that clear), and HttpSig (that name is not settled as it could also be Signature as it was used to be with draft-cavage) for HttpSig Authentication.
We need to make sure they play well together. Is this problem overcome with HTTP/2.0? One could also use new authentication headers that don't come with the baggage of the headers from the 1990ies.
The text was updated successfully, but these errors were encountered:
The RFC7235 syntax for
WWW-Authenticate
andAuthorization
uses,
(commas) to separate key-value pairs rather that semicolons as many other header fields and as suggested by RFC8941 for new header fields. This means that one has to be very careful when parsing concatenatedWWW-Authenticate
orAuthorization
headers. This was discussed in Clarify multiple authorization header behaviour or concatenation method issue on the http-core repo in Nov 2018. I am not 100% sure what the result of that discussion was.We have potentially a few Authentication methods we would like to allow. At least:
Basic
,Bearer
(for Solid-OIDC I guess, but the spec does not make that clear), andHttpSig
(that name is not settled as it could also beSignature
as it was used to be with draft-cavage) for HttpSig Authentication.We need to make sure they play well together. Is this problem overcome with HTTP/2.0? One could also use new authentication headers that don't come with the baggage of the headers from the 1990ies.
The text was updated successfully, but these errors were encountered: