Header values are being inconsistently split and sometimes joined in HttpHeadersCollection

Description

When reading a single header value from HttpHeadersCollection using TryGetValues I am getting multiple items in the enumerable when I only expect one and sometimes one value when I expect multiple.

Expected behavior

For example, the following HTTP-header should only result in a single value.

Posted:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Result:

"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0"

Actual behavior

Instead I receive 4 items in the enumerable.

Posted:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Result:

"Mozilla/5.0"
"(Windows NT 10.0; Win64; x64; rv:109.0)"
"Gecko/20100101"
"Firefox/110.0"

Even stranger, if I post multiple User-Agent headers I get a single value containing both when in this case I would have expected two.

Posted:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Result:

"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0,Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0"

Summary

This behavior is confusing and inconsistent at best and the cause of bugs at worst. Not to mention it is not at all what is expected when compared to how ASP.NET works.

As a consumer I shouldn't have to do a bunch of string parsing and string joins to reconstruct what the original headers might have been, I should be able to read the header values just as they were sent.

Start by tracing HttpHeadersCollection.TryGetValues, using the single- and repeated-User-Agent examples in the report as reproduction cases. Compare the returned enumerable with the headers as sent, and consider the issue complete when single values are not split and repeated header values remain distinguishable without consumer-side parsing or joining.