HttpHeaders.TryAddWithoutValidation different behaviour between .net 6 and .net 7/8

[przemyslawstepala-gc]

Description

HttpHeaders.TryAddWithoutValidation different behaviour between .net 6 and .net 7/8.

Reproduction Steps

Create simple console application:

internal class Program
{
    static void Main(string[] args)
    {
        using var message = new HttpRequestMessage();
        message.Content = new StringContent("Test");
        message.Content.Headers.TryAddWithoutValidation("Content-Type", "application/json");

        Console.WriteLine(message.Content.Headers);
    }
}

If you create this application in .net 6 you will receive result:

Content-Type: application/json, text/plain; charset=utf-8

application/json will be first and separated from default text/plain; charset=utf-8 by a coma.

In .net 7 or .net 8 you will receive:

Content-Type: text/plain; charset=utf-8, application/json

application/json is last.

This creates problems because later when we are sending HttpRequestMessage only text/plain is sent and we receive 415 Unsupported Media Type response.

Expected behavior

Results from .net 6 would be expected.

Actual behavior

Results from .net 8.

Regression?

No response

Known Workarounds

Check if you already have header before you use TryAddWithoutValidation

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[MihaZupan]

The StringContent constructor will already set the content-type header for you.
If you change your example to use Add instead of TryAddWithoutValidation, you will see FormatException: Cannot add value because header 'Content-Type' does not support multiple values..

You should remove the existing header first, or preferably use the constructor itself to set the value new StringContent("Test", Encoding.UTF8, "application/json"), as that is more clear, avoids unnecessary use of unsafe logic, and is more efficient.

What you're looking at is the result of a bugfix for #63833 that stopped reordering invalid/unparsed values in the list when sending those over the network.
Both values are sent to the server in .NET 6 or in newer versions, but their order now reflects the order in which they were added.
In .NET 6: application/json, text/plain; charset=utf-8
In .NET 7+: text/plain; charset=utf-8, application/json
It's likely that the server you're using is only looking at the first value, and so things happened to work with the interaction between the bug in your code and the bug in HttpHeaders.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.