How to handle/cleanse invalid 0x14 in XML using Linq? - c#

I'm working on a C# client that downloads XML files from a web service via SOAP. For some of the older records hosted on the service, the XML comes across with, apparently, a 0x14 buried somewhere in it, which kicks an "Invalid whitespace character" exception. I'm using Linq to dump the XML into files. Is there some way to instruct Linq to dispose of invalid characters without losing the rest of the XML?
EDIT:
Here's the code I currently have for putting the XML to file:
XDocument c =
new XDocument(
new XElement(nameSpace + "getCitationsResponse",
new XAttribute(XNamespace.Xmlns + "ns1", nameSpace),
new XElement("list",
record.reportDateSpecified ? new XElement("reportDate", record.reportDate) : null,
new XElement("reportType", record.reportType),
new XElement("title", record.title),
new XElement("projectNumber", record.projectNumber),
new XElement("author", record.author),
new XElement("abstract", record.#abstract),
new XElement("numPages", record.numPages),
record.isDataTypeSpecified ? new XElement("isDataType", record.isRestrictedData) : null,
new XElement("comments", record.comments),
new XElement("attachments", from a in record.attachments
select new XElement("list",
new XElement("id", a.id),
new XElement("filePath", a.filePath),
new XElement("type", a.type)))));
I had to hack out some of it for the usual reasons, but what I removed is identical to the what's shown here.
I used SoapUI before I posted to see if I could figure out where the flaw was, but I don't see anything in SoapUI, and it doesn't generate an error itself.
EDIT #2:
Here's the exact error message and stack trace. Makes me wonder if I can actually do something about it or if I just need to work in something to log which records have invalid characters and try to pull 'em down manually with SoapUI.
Invalid white space character (0x14) in text to output
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Downloader.WebService.ApiService.getRecords(String username, String[] ids)
at Downloader.Central.RecordLoop(ApiService svc, Int32 offset, String username)
getRecords is the API call generated by the wsdl, and RecordLoop is a recursive function I wrote to handle iterating through the API call to find updated records and push them to the Linq function I posted already.

As mentioned in some of the comments above, it's possible to do execute different ninja tricks to get the SOAP response to comply with the XML specification.
If you choose to change the response to make it valid XML, you have to seriously consider if your changes are changing the meaning of the response.
As I see it, the problem is not on your side, but on the service side. If you can, you should try to get the service owner to upgrade the service to deliver proper formatted XML in their web services.
When dealing with 3rd party web services, I normally do the following:
Enable full XML Schema validation on any requests and responses to and from 3rd web services. If the requests or responses aren't XML schema valid, then we (client and service) have a problem, which can be minor or major - but at least it's being attended to.
Always log any schema validation errors, before trying to fix the content, to be sure that it's on record.
Ensure that I'm fully aware of the system, business or legal implications on modifying the content.
Ensure that I'm encoding the response using the proper encoding format - UTF8, Latin1 or others.
Invalid content is typically xml text elements, that contain illegal XML characters. The service side should either use XML encoding or base64 encoding, when transferring such text nodes, both to preserve formatting as well as content.
On the more technical part of actually changing the content so it become valid, I would normally add WCF behaviours, that would address the issues as doing so, kind of separate the concerns of fixing up the xml and the business purpose of service invocation.
It's also easy to remove the WCF behaviour, if or when the service gets updated to provide valid XML at any request.

Related

C# SOAP client: sending generic XmlNode request

I have a C# project where I added a SOAP service reference, using the integrated visual studio functionality (right click -> add -> service reference)
The client classes are generated correctly without errors. However, the various methods of the service only accept a generic System.Xml.XmlNode as an input, rather than a structured object.
This should not be a problem in theory, since I have the complete XML file with the query that I need to perform. So I tried doing it like this:
NSIStdV20ServiceSoapClient client = new NSIStdV20ServiceSoapClient();
var getAllDataFlowQuery = File.ReadAllText(#"Query\get_all_dataflow.xml"); //file containing the query
XmlDocument doc = new XmlDocument();
doc.LoadXml(getAllDataFlowQuery);
var dataStructures = client.QueryStructure(doc); //this method accepts a System.Xml.XmlNode as parameter
However, this doesn't work, throwing
System.ServiceModel.FaultException: 'Error due to a non correct client message'
I thought initially that the query was incorrect, but I tried to perform the exact same query using SoapUI and it works perfectly! I even tried doing it with the exact XML returned by doc.InnerXml (just to be sure che XmlDocument object was not modifying the XML) and it works.
So basically it's only when calling the method from C# that it doesn't work.
If you want to try it out yourself, the service is freely accessible, the WSDL is here:
http://sdmx.istat.it/SDMXWS/NsiStdV20Service.asmx?WSDL
and you should try to call the QueryStructure method with the following payload:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://ec.europa.eu/eurostat/sri/service/2.0"><soapenv:Header /><soapenv:Body><web:QueryStructure><!--Optional:--><web:Query><RegistryInterface xsi:schemaLocation="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/message SDMXMessage.xsd" xmlns="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/message" xmlns:common="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/common" xmlns:compact="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/compact" xmlns:cross="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/cross" xmlns:generic="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/generic" xmlns:query="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/query" xmlns:structure="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/structure" xmlns:registry="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/registry" xmlns:utility="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/utility" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Header><ID>JD014</ID><Test>true</Test><Truncated>false</Truncated><Name xml:lang="en">Trans46302</Name><Prepared>2001-03-11T09:30:47-05:00</Prepared><Sender id="BIS" /></Header><QueryStructureRequest resolveReferences="false"><registry:DataflowRef /></QueryStructureRequest></RegistryInterface></web:Query></web:QueryStructure></soapenv:Body></soapenv:Envelope>
As I said, this works perfectly in SoapUI, but doesn't work when calling the client method from C#
Well, it seems that the client generated by visual studio, even tho it accepts a XmlNode as input, creates some of the required outer structure itself (to be precise: all the outer nodes with the soapenv and web namespaces).
Which means I had to strip down the input XML to:
<?xml version="1.0" encoding="UTF-8"?><RegistryInterface xsi:schemaLocation="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/message SDMXMessage.xsd" xmlns="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/message" xmlns:common="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/common" xmlns:compact="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/compact" xmlns:cross="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/cross" xmlns:generic="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/generic" xmlns:query="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/query" xmlns:structure="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/structure" xmlns:registry="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/registry" xmlns:utility="http://www.SDMX.org/resources/SDMXML/schemas/v2_0/utility" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Header><ID>JD014</ID><Test>true</Test><Truncated>false</Truncated><Name xml:lang="en">Trans46302</Name><Prepared>2001-03-11T09:30:47-05:00</Prepared><Sender id="BIS" /></Header><QueryStructureRequest resolveReferences="false"><registry:DataflowRef /></QueryStructureRequest></RegistryInterface>

How to serialize an object into string\xml with its headers

I'm using a third side web service client (created by using the "Add service reference") in order to retrieve some data.
After filling the web service objects with proper data we need to add some data to the headers (encrypted password and some other predefined data)
Then, we are serializing every request sent to the web service, using the standard .net XmlSerializer.
However, in the result of the serialization I don't see the headers of the request. I've searched for a long time and couldn't find any way to "print" them as well.
Here is some example code:
Ibooking proxy = new BookingManager();
/* Init proxy Data...*/
GetAvailabilityRequest request = new GetAvailabilityRequest();
/*Fill more data on the request...*/
GetAvailabilityResponse response = proxy.GetAvailability(request); //Send request to the web service
var xmlString2 = response.Serialize(); //only body, no headers in the XML
/* Extension class to Serialize any object */
public static class ExtensionUtil
{
public static string Serialize<T>(this T value)
{
try
{
XmlSerializer xmlserializer = new XmlSerializer(typeof(T));
var stringWriter = new StringWriter();
using (var writer = XmlWriter.Create(stringWriter))
{
xmlserializer.Serialize(writer, value);
return stringWriter.ToString();
}
}
catch (Exception ex)
{
throw new Exception("An error occurred", ex);
}
}
}
I've excluded the code that adds more data to the request since it's long and complicated (need to implement IEndpointBehavior and IClientMessageInspector to "catch" the request before we send it) - but currently as a workaround I put a BreakPoint on the Message object and convert it into string using Visual Studio. In this way I do see the headers but obviously this is bad practice since I want it to be automated in the serialization.
I would like to see an example of how you are adding these headers.
In most web services the message body is the part that is serialized into XML or JSON - the headers are not.
You may be able to inspect the service call by using Fiddler and a proxy implemented by a small change in your web.config as described in this article: http://weblog.west-wind.com/posts/2008/Mar/14/Debugging-Http-or-Web-Services-Calls-from-ASPNET-with-Fiddler.
The short version of this is to add the following to your web.config or app.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
Download and run Fiddler while calling the service and you should see and be able to inspect the call in Fiddler.
If you want to inspect and/or modify the headers within your code base could look into implementing IClientMessageInspector or IDispatchMessageInspector. Here are a couple articles on the topic:
https://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.iclientmessageinspector(v=vs.100).aspx
http://weblogs.asp.net/paolopia/writing-a-wcf-message-inspector
Here is an implementation I did. I didn't need access the headers, but rather to modify the xml namespaces created by the service client, but it should give you an idea on how to do the implementation: How can I create custom XML namespace attributes when consuming a legacy SOAP service?
OperationContext is your friend here. Use an OperationContextScope to wrap the call to the service, then use OperationContext.Current to get at all the hidden goodies you need.
https://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontextscope(v=vs.110).aspx
Note that you'll need to know the specific types of the headers you want to get at, and I've had some trouble getting at the values, rather than just the names, of headers if they're not marked as serializable when using XmlSerializer

.NET 4.6 HttpResponse.PushPromise methods to manage http/2 PUSH_PROMISE header

I am a bit confused about PUSH PROMISE http/2 header handling in .NET4.6.
When I look HttpResponse.PushPromise there are two overloads:
One that accepts path to resource public void PushPromise(string path) - am assuming resource is then read and binary sent across to client.
Second public void PushPromise(string path, string method, NameValueCollection headers) that accepts sting method and NameValueCollection headers which I am failing to understand.
Why would I want to pass method (assuming HttpMethod like GET, POST, etc) and collection of headers inside PUSH PROMISE header?
From reading the HTTP/2 spec (Section 8.2), here is what I gather:
Passing the method
PUSH_PROMISE frames are required to be cacheable and safe. You have the option of using GET and HEAD, as those are the only two http methods that are defined as both safe and cacheable.
Passing headers
Since PUSH_PROMISE frames are required to be cacheable, this could be used to add specific Cache-Control directives to the promise. Section 8.2.2 of the spec states that a client has the option to download the promised stream and can refuse it, which I imagine a client would do if it found that it had an up-to-date version of the resource in its cache.
Controlling caching is the most obvious reason I can see for why you might pass headers, but there may be other reasons as well. If you're writing a custom client, you may use certain X-Headers to provide other hints (that aren't related to caching) to the client so it can decide whether or not it wants to accept the promised stream.
You'll want to pass headers for anything that will cause your response to vary (i.e. anything in your Vary response header). The biggest one I've found is compression.
Read those headers from the original client request and include them with your push promise, e.g.:
var headers = new NameValueCollection { { "accept-encoding", this.Request.Headers["accept-encoding"] } };
this.Response.PushPromise("~/Scripts/jquery.js", "GET", headers);`

Encountered invalid root element name 'HTML'. 'root' is the only allowed root element name

i am using msdn sample code and it has jsonp wrapper files you can find the code here
of this article and MSDN article JSON with Padding (AJAX)
but when i run the code it throw me this error:
Encountered invalid root element name 'HTML'. 'root' is the only allowed root element name
what does it mean?
It means that you've made some kind of web request that is expecting to get some kind of XML data back but instead it is getting HTML data back. The usual cause is a messed up URL. If your URL were correct, then XML would be returned as expected. Since it is messed up you end up getting back HTML (probably an error page at that).
Check your URLs to make sure they are correct.
I found the solution to similar problem. In my case, I was getting similar error, when my service was returning raw JSON, that is to say it was returning a Stream which represented this JSON.
The error was: Encountered invalid root element name 'Binary'. 'root' is the only allowed root element name.
The problem is that the MS provided example uses JsonWriter to take convert the message to JSON, but this writer expects that your message consists of JSON objects which he can convert to Stream. In my case the message was compose of binary data, so instead of one "root" element I was having "Binary" element.
I got over this issue by modifying classes provided by the MS sample. Basically I check the format of the message - if it is JSON I can still use the JsonWriter, if it is Binary, I have to take a different approach. In your case the message is in HTML format (I am not sure how do you serve it), but you will find a different way to get the body of the message.
I wrote a blog post about my issue here: http://hoonzis.blogspot.com/2011/07/provide-jsonp-with-your-wcf-services.html
Hope it helps a bit, Honza
I ran into the same error message but in a different scenario. I was adding JSON support to a WCF web service that only supported XML.
Specifically I wanted to return the error messages object in JSON also.
I had a class that was implementing System.ServiceModel.Dispatcher.IErrorHandler. Within the ProvideFault method I was setting the `WebBodyFormateMessageProperty to the corresponding one wither, XML or JSON based on what it was passed in the accept header. I was also setting the content type accordingly. What I was missing was using the correct serializer for each case
Dim webBodyFormatMessageProp As Channels.WebBodyFormatMessageProperty
Dim contentType As String
Dim serializer As XmlObjectSerializer
If WebOperationContext.Current.OutgoingResponse.Format = WebMessageFormat.Json Then
webBodyFormatMessageProp = New System.ServiceModel.Channels.WebBodyFormatMessageProperty(System.ServiceModel.Channels.WebContentFormat.Json)
contentType = "application/json"
serializer = New DataContractJsonSerializer(GetType(MyErroClass))
Else
webBodyFormatMessageProp = New System.ServiceModel.Channels.WebBodyFormatMessageProperty(System.ServiceModel.Channels.WebContentFormat.Xml)
contentType = "text/xml"
serializer = New DataContractSerializer(GetType(MyErroClass))
End If
Dim detail = faultException.[GetType]().GetProperty("Detail").GetGetMethod().Invoke(faultException, Nothing)
fault = System.ServiceModel.Channels.Message.CreateMessage(version, "", detail, serializer)
fault.Properties.Add(System.ServiceModel.Channels.WebBodyFormatMessageProperty.Name, webBodyFormatMessageProp)
Dim httpResponseMessageProp = New System.ServiceModel.Channels.HttpResponseMessageProperty()
httpResponseMessageProp.Headers(System.Net.HttpResponseHeader.ContentType) = contentType
httpResponseMessageProp.StatusCode = System.Net.HttpStatusCode.OK
httpResponseMessageProp.StatusDescription = [error].Message
fault.Properties.Add(System.ServiceModel.Channels.HttpResponseMessageProperty.Name, httpResponseMessageProp)
Apologize for the VB.net but that is what I am currently working on.

How to get XMLResponse from Webservice in c# Soap or other soap

I want to integrate with webservice writes in php (PEAR SOAP).
Wsdl file is without types definition.
When i was connect to webservice i getting a null response.
In WebServiceStudio i see xmlrequest and xmlresponse, my I get xmlresponse in c# default soap or other soap.
I know what is causing the null response. PEAR SOAP returnx STRUCT[X] as a response type, where X is number of list element.
When I my get XMLresponse and replace this section then it would be cool
Regards
Sorry for my english
The method you need is getLastResponse(), but if it's anything like other, similar HTTP-stream classes, you'll probably need to set a flag to enable capturing the raw requests/responses. Then again, maybe not, since you apparently have to use parseResposne to get the data out of the XML.
Try:
$soapClient->call(some,parameters,here);
$response = $soapClient->getLastResponse();
echo $response;

Categories