Unwanted/Risky UTF8 Byte Order marks at the start of the http responses.

[myobis]

Further to minor glitches in some client code, I used Telerik Fiddler (HexView mode), to confirm that SoapCore is generating UTF8 Byte Order Marks at the very beginning of the http response bodies.

This is useless and possibly harmful.

The case that I noticed can be easily fixed in SoapEncoderOptions.cs replacing
Encoding.UTF8 by new UTF8Encoding(encoderShouldEmitUTF8Identifier: false) .

This being said, there are plenty of other occurences of "Encoding.UTF8" in the code.. some are not a problem like Encoding.UTF8.GetBytes(string), others might be.

[andersjonsson]

@myobis Nice catch! Thanks

Mind checking out my PR to see if that fixes the issue?
I get nervous changing things like this, but I find it unlikely that someone would depend on the BOM being there

[myobis]

@andersjonsson , thanks for the fix.

First, your fix does work for my client relying on UTF8: no more glitches 👌.

I also have the following comment about your PR :

I'm not a regular user of Unicode and BigEndianUnicode encodings. However, if it is similar to UTF8, I guess there should be no BOM at the start of the http response bodies for these encodings as well.
The following dotnetfiddle ( https://dotnetfiddle.net/t3J1xl ) shows that they all have BOMs and suggests respective replacements using new UnicodeEncoding(bool, bool) :

You might want to adjust DefaultEncodings.cs accordingly.

[andersjonsson]

I'm not a regular user of Unicode and BigEndianUnicode encodings. However, if it is similar to UTF8, I guess there should be no BOM at the start of the http response bodies for these encodings as well.

Since the charset is set to utf-16LE or utf-16BE in those cases I think you are correct.
From the Wikipedia page on UTF-16
"For the IANA registered charsets UTF-16BE and UTF-16LE, a byte order mark should not be used because the names of these character sets already determine the byte order."