XSLT to remove namespace is failing because of invalid character in xml

I have a soap to rest api and default xslt to remove namespace is failing because of invalid characters in response. @Dino @Anil Sagar

<ns2:Memo>31195�@*</ns2:Memo> 

Is there anyway this can be handled using javascript or XSLT. We are not bothered about what is inside of that XML. We just want to remove the namespace, transform it to JSON and send to client. We just want to remove the namespace, transform it to JSON and send to client.

1 1 982
1 REPLY 1

If you have characters like that, it's not well-formed XML.

That means Apigee Edge will not handle it as XML. Apigee Edge is behaving correctly.

Characters like that can appear in the payload for several reasons.

  1. because the peer is not encoding the XML correctly (typically it should be done with utf-8), OR
  2. because the actual encoded information is not tagged with the right content-type (for utf-8 it should be something like "Content-Type: text/xml; charset=utf-8") OR
  3. because the receiver (Apigee Edge?) is not correctly handling the encoding.

The last case is unlikely, since Apigee Edge is designed to respect the Content-type header and do the right thing.

.................

If I were doing this, I would try, in this order:

  1. to get the encoding to be done properly. This means modifying the Accept header sent by Apigee Edge, or getting the peer to set the correct the content-type header, or getting the peer to correct the encoding of the XML document itself.
  2. parse the "xml" in a Javascript callout to remove the non-ASCII bytes, save it back to response.content. It will now be "well formed". and then the XSLT policy will work as expected. This is really a hack, and I don't recommend it unless you just can't get the encoding right.

..............

I've seen this happen when an application used Java to serialize an object containing Unicode strings to XML but did not specify the UTF-8 encoding on the output stream. The fix was to correct that output stream.