Runtime: HttpClient still forcing spaces into Accept headers

[parxal]

HttpClient forcing spaces into Accept headers with parameters breaking non-conforming REST.
When setting httpClient accept header. Strings are forced with a space between the ;
This as been reported here :
https://github.com/dotnet/corefx/issues/18449
https://github.com/dotnet/corefx/issues/22472

But still happens in version 2.2
```c#
static void Main(string[] args)
{
var httpClient = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, "http://google.com");
request.Headers.Add("Accept", "application/json;version=1");
var result = httpClient.SendAsync(request).Result;
Console.ReadLine();
}

If you check Fiddler, accept is : "application/json; version=1" and not "application/json;version=1" , there's a space after ; 

Unfortunately some API's don't work well with this space.  Is there any workaround?

WebRequest have the same behaviour as well. witch didn't happen in net  framework 4.5 
```c#
var webRequest = (HttpWebRequest)System.Net.WebRequest.Create($"http://google.com");
webRequest.Method = "POST";
webRequest.Accept = "application/json;version=1";
webRequest.GetResponse().GetResponseStream();

[davidsh]

But still happens in version 2.2

Can you please try .NET Core 3.0? It is available in Preview:
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-6/

[davidsh]

According to RFC 7231 Section 5.3.2 the grammar for the 'Accept' request header allows for whitespace characters after the semicolon. Whitespace characters are defined by 'OWS' RFC 7231 Section 3.2.3. 'OWS' is "optional whitespace" defined as zero or more occurrences of a space character or a tab character.

Furthermore, the examples in the RFC show whitespace characters after the semicolon characters.

The RFC says that clients writing to the network should use a white-space character. That would imply that .NET Core HttpClient/HttpWebRequest APIs are following the RFC:

The OWS rule is used where zero or more linear whitespace octets
might appear.  For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP

Unfortunately some API's don't work well with this space. Is there any workaround?

What servers are you using that don't work well? They appear to not be following the RFC.

[parxal]

In this specific case is cabify api (uber similiar company) , but it's not the only one, there's more persons with same problem in stackoverflow :
https://stackoverflow.com/questions/40152607/httpclient-in-netcore-is-automatically-adding-a-space-in-header
https://stackoverflow.com/questions/45194549/httpclient-httprequestmessage-accept-header-parameters-cannot-have-spaces

You shoud have the option or at least HttpWebRequest should have continue te same behaviour.

[karelz]

Triage: We should not normalize in Add(string, string).
It will be technical breaking change. But it will also help perf -- see related https://github.com/dotnet/runtime/issues/30400.

[parxal]

@karelz thanks for the feedback, in what version will that happen?

[karelz]

No plans from us at this moment. We are willing to take a contribution though.

[developervariety]

I'm running into this issue too. Only solution for me is to use a non-async library xNet.. which fulfills my needs, but no asynchronous support which is a downfall.

[ClimberBear]

Same problem with net core 3.0.0.
I'm suffering same bug with a big public API server (https://publications.europa.eu/), publications office for all European Union

[karelz]

Please upvote top post if you hit this issue - "me too" replies are easy to miss and hard to count.

[ClimberBear]

Please upvote top post if you hit this issue - "me too" replies are easy to miss and hard to count.

Thanks! Done!

And (IMHO) this is not an enhancement. It's clearly a bug. No code has to be allowed to change the data.

[crima]

I've got the same issue. I'm forced to use a REST API wicht cannot recognize the Content-Type if there is a space in semicolon and parameter. I'm using the method MediaTypeHeaderValue.Parse() which adds a space. I've already contacted the vendor about this issue, but I don't think that they will fix that very soon.
But I would also expect from the framework to let the data as it is and not to change them.

[WillMagno]

I fixed this problem and made a pull request.

https://github.com/dotnet/runtime/pull/792