UTF-8 BOM is added to raw value response when running on ASP .NET Core 3+

[VirusQuartirus]

Assemblies affected
ASP.NET Core OData 7.x

Describe the bug
When client sends request that expects raw value to be returned ($count for example) and doesn't specify Accept-Charset header UTF-8 BOM is written prior to content and Content-Type: text/plain. This happens when application is built using ASP .NET Core 5+ 3+.

Reproduce steps
See attached Fiddler logs.

Possible solution
It looks like ASP .NET Core 5 changed behavior of Microsoft.AspNetCore.Http.Headers.RequestHeaders class and now properties like AcceptEncoding AcceptCharset return empty collection instead of null value. It looks like it may be fixed in ODataOutputFormatter.WriteResponseHeaders change current line

if (requestHeader != null && requestHeader.AcceptCharset != null)

to

if (requestHeader?.AcceptCharset?.Count > 0)

FiddlerLogs.zip

[julealgon]

The change in behavior you describe seems to indeed exist:

• Return an empty list instead of null for IHeaderDictionary extensions… dotnet/aspnetcore#10972

However, it appears to have been made in AspNetCore 3. You sure this only happens in 5+?

Also, you mention AcceptEncoding but then add code that mentions AcceptCharset. Was that intentional?

For future reference, actual link:

AspNetCoreOData/src/Microsoft.AspNetCore.OData/Formatter/ODataOutputFormatter.cs

Lines 197 to 207 in 69eec03

	if (requestHeader != null && requestHeader.AcceptCharset != null)
	{
	IEnumerable<string> acceptCharsetValues = requestHeader.AcceptCharset.Select(cs => cs.Value.Value);
	string newCharSet = string.Empty;
	if (TryGetCharSet(currentContentType, acceptCharsetValues, out newCharSet))
	{
	currentContentType.Charset = new StringSegment(newCharSet);
	response.Headers[HeaderNames.ContentType] = new StringValues(currentContentType.ToString());
	}
	}

[VirusQuartirus]

However, it appears to have been made in AspNetCore 3. You sure this only happens in 5+?

Indeed, 3.x also suffers from this issue.

Also, you mention AcceptEncoding but then add code that mentions AcceptCharset. Was that intentional?

Just a typo. However all collection returning properties are affected.

[KenitoInc]

@VirusQuartirus
We welcome contributions. We will be happy to review your PR.

[VirusQuartirus]

@VirusQuartirus We welcome contributions. We will be happy to review your PR.

I don't have write permissions to this repo.

[julealgon]

I don't have write permissions to this repo.

That's usually how it works with public repositories. You don't create branches directly in the target repo: instead, you fork the repository to your account, make your branch and changes there, and then submit a pull request to the target repo from your fork.

This flow doesn't require you any kind of write permission on the target repo.

[VirusQuartirus]

That's usually how it works with public repositories. You don't create branches directly in the target repo: instead, you fork the repository to your account, make your branch and changes there, and then submit a pull request to the target repo from your fork.

This flow doesn't require you any kind of write permission on the target repo.

Thanx for the tip. PR is created #630