Question

Using Visual Studio 2008, I setup a client that uses Web Services.
It has nothing to do with buffer sizes (as that is a typical response, all appropriate sizes were increased).

I was using a List as the parameter of the Method.
After much experimentation, I used the System.Net.WebClient to manually create a Soap 1.1 and a Soap 1.2 request to test test the result.

using (var webCtx = new System.Net.WebClient())
{
  webCtx.Headers.Add(System.Net.HttpRequestHeader.ContentType, "text/xml");
  webCtx.Headers.Add("SOAPAction", "http://tempuri.org/HelloWorld");
  var uri = new Uri("http://localhost:12345/MyProject/WebService.asmx");
  MessageBox.Show(webCtx.UploadString(uri, xml));
}

Where the xml is a string variable of the xml with actual data.
The problem is when one of the fields has a special character. Here is the example of the message body of the xml.

<PocoClass>
  <UnicodeString>&#xE;123</UnicodeString>
</PocoClass>

If the value of UnicodeString was something simple (i.e. 123), but once the special character appeared, I got 400 Bad Request.

Now, I have found a Microsoft Knowledge Base Article describing the bug kb911276, which basically states, install a hot fix. That really isn’t something that can be a solution to the problem, so I was wondering if there are any ideas of how to solve this problem?

Are the only solutions to write some sort of custom encoding/decoding or custom bindings to be implemented by the server and client? Are there any easier ideas?

Thanks

Edited:
The use of a List is not an issue as it is handled by VS. Here is a more complete (but still partial) contents of the soap message.

<HelloWorld xmlns="http://tempuri.org/">
  <pocoList>
    <PocoClass>
      <UnicodeString>&#xE;123</UnicodeString>
    </PocoClass>
  </pocoList>
</HelloWorld>

Answer 1

I had a similar problem with a webservice we had that users of our app run online account searches. I found a VS Feedback item about this, but it appears MS considers this behaviour by-design.

What we ended up doing was writing a method that replaced all characters that are not allowed when serializing to XML with question marks.

The allowed list was: 0x09, 0x0a, 0x0d, 0x20-0xd7ff, and 0xe000-0xfffd. Everything else, we turned to “?”.

I guess if you can’t do that, the data should be base64-encoded in transit to avoid this issue. Seems a bit odd to me, as it breaks the ability to losslessly route a call through a web service.