WebServices fail because (400) Bad Request because of special character.

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/"&gt;
  <pocoList>
    <PocoClass>
      <UnicodeString>&#xE;123</UnicodeString>
    </PocoClass>
  </pocoList>
</HelloWorld>

Answer 1

My concern is where you state that you are using a List as the parameter to a method. Web services don't directly support lists. You need to use an array as the parameter. Then internally you can convert it to a list using .ToList(). This may not be your issue directly!

Answer 2

That KB article was referring to unicode character sets within a request URL, not actual data being posted to the server.

That being said; i'd verify that your headers are well formed.

Also, if VS generated the client proxy for you; right click on the service reference and then on "Update Service Reference"

Just noticed one more thing; you said that you are passing in a list as a parameter; from the snippet of xml shown, that doesn't look like something that would be serialized from a list (by any of the .NET xml serializers); if you want to debug using the webclient approach; try verifying that the format of the xml is valid.

Answer 3

Where are you seeing ? In the raw XML or the serialized data? XML is defined to contain only human-readable characters and  is the XML entity for the unreadable ASCII Shift-Out character. If you're looking at the raw XML and it contains the XML entity code, that's allowed, but if you are looking at serialized data and your XML document contains raw control characters it is invalid and will be rejected.

Answer 4

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.