{"id":10299,"date":"2005-11-01T12:20:09","date_gmt":"2005-11-01T17:20:09","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/buckh\/?p=10299"},"modified":"2019-05-06T12:20:51","modified_gmt":"2019-05-06T16:20:51","slug":"validating-xml-characters-in-soap-messages","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/buckh\/validating-xml-characters-in-soap-messages\/","title":{"rendered":"Validating XML characters in SOAP messages"},"content":{"rendered":"

I’ve written about using the SoapHttpClientProtocol subclasses generated by wsdl.exe several times over the last year, including handling authentication<\/A>, HTTP response codes<\/A>, and setting timeouts properly<\/A>.  Today I needed to change the code in TFS to better handle characters that are not allowed in XML.<\/P>\n

The problem is that if you have a method on your web service that takes a String parameter, someone may call that method with a string that contains characters that are not allowed in XML.  That input may come from a command line switch or a text box in a GUI.<\/P>\n

The XmlWriter used by SoapHttpClientProtocol is XmlTextWriter<\/A>.  XmlTextWriter doesn’t do any character validation.  If the string passed to WriteString() includes characters that are not valid for XML, your XML output will also.  The characters below 32, except for tab, carriage return, and new line, the UTF-8 BOM, and invalid surrogate pairs are not allowed by the XML standard.<\/P>\n

The XmlReader used by the ASP.NET web services does do character validation.  If it finds an invalid XML character, the web service will respond with HTTP 400 Bad Request.  That doesn’t help the user figure out what’s going on.<\/P>\n

Elena Kharitidi<\/A> suggested overriding the GetWriterForMessage()<\/A> method from SoapHttpClientProtocol in the subclass that was generated by wsdl.exe and providing a character-validating XmlWriter.<\/P>\n

The documentation shows an example of creating a subclass of XmlTextWriter to check the characters<\/A>.  However, it would be better to be able to use a framework class to do it without rolling our own.  Fortunately, there is such a class in the framework.<\/P>\n

With a little poking around, I found the XmlCharCheckingWriter class that is internal to the framework.  Now we just need to get the framework to give us an instance of that class.  A little more poking around and experimentation resulted in the piece of code shown below.<\/P>\n

If you run it under the debugger and put a breakpoint on line 5, you’ll see that the base SoapHttpClientProtocol method returns an XmlTextWriter.  If you step down to the XmlWriter.Create() call, you’ll see that the framework gives us the XmlCharCheckingWriter instance that we want in response to the CheckCharacters setting being true.<\/P>\n

Now, if you add the following code to your wsdl.exe-generated subclass of SoapHttpClientProtocol, you’ll get an ArgumentException on the client when trying to write the invalid XML in the SOAP message.  The exception message will state that there is an invalid character.  The result is a significant improvement over getting a generic HTTP 400 Bad Request from the web service.<\/P>

\/\/ Override this method in order to put in character validation.<\/SPAN>\nprotected<\/SPAN> override<\/SPAN> XmlWriter GetWriterForMessage(SoapClientMessage message,\n                                                 int<\/SPAN> bufferSize)\n{\n    XmlWriter writer = base<\/SPAN>.GetWriterForMessage(message, bufferSize);<\/p>\n
    \/\/ Choose the encoding the same way the framework code does.<\/SPAN>\n    Encoding encoding = RequestEncoding != null<\/SPAN> ? RequestEncoding :\n                                                  new<\/SPAN> UTF8Encoding(false<\/SPAN>);<\/p>\n
    \/\/ We want the character validation to be done on the client side<\/SPAN>\n    \/\/ rather than getting an obscure HTTP 400 Bad Request message<\/SPAN>\n    \/\/ from the server (the XmlReader used by the web services does <\/SPAN>\n    \/\/ character validation, while the writer used in the base class<\/SPAN>\n    \/\/ does not).<\/SPAN>\n    \/\/ We create this second XmlWriter to get an XmlCharCheckingWriter<\/SPAN>\n    \/\/ instance.  The Create(XmlWriter, XmlWriterSettings) code path <\/SPAN>\n    \/\/ does that (we don’t need the overhead in an XmlWellformedWriter).<\/SPAN>\n    XmlWriterSettings xws = new<\/SPAN> XmlWriterSettings();\n    xws.Encoding = encoding;\n    xws.Indent = false<\/SPAN>;\n    xws.NewLineHandling = NewLineHandling.None;\n    xws.CheckCharacters = true<\/SPAN>;      \/\/ make sure char is valid for XML<\/SPAN>\n    writer = XmlWriter.Create(writer, xws);<\/p>\n
    return<\/SPAN> writer;\n}\n<\/PRE><\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve written about using the SoapHttpClientProtocol subclasses generated by wsdl.exe several times over the last year, including handling authentication, HTTP response codes, and setting timeouts properly.  Today I needed to change the code in TFS to better handle characters that are not allowed in XML. The problem is that if you have a method on your web service that takes […]<\/p>\n","protected":false},"author":94,"featured_media":10268,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-10299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"blog_post_summary":"
I’ve written about using the SoapHttpClientProtocol subclasses generated by wsdl.exe several times over the last year, including handling authentication, HTTP response codes, and setting timeouts properly.  Today I needed to change the code in TFS to better handle characters that are not allowed in XML. The problem is that if you have a method on your web service that takes […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/10299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/comments?post=10299"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/10299\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media\/10268"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media?parent=10299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/categories?post=10299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/tags?post=10299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}