HttpClient send with no-ascii header value throw exception

[summeney]

header value is no-ascii. we should pass.
but....

HttpConnection.cs
await WriteStringAsync(header.Value[0]).ConfigureAwait(false);

throw exception in WriteStringAsync

                if ((c & 0xFF80) != 0)
                {
                    throw new HttpRequestException(SR.net_http_request_invalid_char_encoding);
                }

boom...............

[scalablecory]

While HTTP 1.1 does allow non-ascii data in headers, later revisions recommend against it and we follow this recommendation.

This is because there is no encoding defined beyond US-ASCII, and no way for a header to specify its encoding -- anything using this feature would be very fragile as every implementation might treat it differently.

[davidsh]

We have some code in the HTTP protocol stack that allows for receiving headers that have non-ASCII in them (similar to browsers being lenient). But writing out headers with non-ASCII is strictly not allowed.

This follows the networking principle of "Be flexible in what you receive and strict in what you send". This helps ensure compatibility with non-compliant servers but also helps promote RFC standards when sending data.

[davidsh]

@summeney Thank you for your feedback on this issue. But the behavior you describe is by-design as discussed.

[GSPP]

It would promote standards even more if any deviation would be disallowed by default. There could be a boolean setting to allow lenient parsing. I'd estimate that 95% of servers that a typical .NET developer wants to talk to over HTTP are strictly conforming these days. In fact, I wonder what non-conforming servers are still out there...

[summeney]

moto z2 has a special user-agent.
https://www.motorola.com.cn/motoz2play/overview/index.html

so .net core cant support alllllllllll moto z2 mobile phone????????????????????????