Link header parsing breaks for multiple links with at least one containing unquoted values

[kdefives]

Hello,

Seems the REGEX used inside Links parse(@ Nullable String source); function is not compliant with a part of RFC8288 Section 3 : https://www.rfc-editor.org/rfc/rfc8288.html#section-3
Related to the usage of "rel" attribute, seems it could be use in both following way (quoted and not quoted value):

• rel=boo
• rel="boo"

Extract from RFC8288:

Link Serialisation in HTTP Headers

The Link header field provides a means for serialising one or more
links into HTTP headers.

The ABNF for the field value is:

Link       = #link-value
link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
link-param = token BWS [ "=" BWS ( token / quoted-string ) ]

Note that any link-param can be generated with values using either
the token or the quoted-string syntax; therefore, recipients MUST be
able to parse both forms. In other words, the following parameters
are equivalent:

x=y
x="y"

The function do not parse the header correctly if we got a rel value without quotes.

I did a fork with a unit test which is failing currently, but if what i am saying is right, it should pass after the fix: #1898

I know a RFC can be misinterpreted so feel free to tell me if i am wrong and if "rel" value MUST be quoted all the time.

Regards,

[odrotbohm]

Good catch! It's not been unquoted values per se, but the combination of multiple links and the regex not properly detecting a value ending at a comma. I applied your PR and expanded the test cases in the actual fix. Backported to 2.0.x and 1.5.x, both due to ship releases this Friday.