CData Section getting escaped in RPC

We see an issue when the rpc reply or for that matter even the rpc request has Cdata section it leads to parse failure. Most likely either the Cdata is section itself is escaped . Below is example of rpc response which does not get parsed by JNC client. Is there a way around this ?

<notification xmlns=“urn:ietf:params:xml:ns:netconf:notification:1.0”>
<eventTime>2019-09-18T18:23:00.54918+00:00</eventTime>
<edit-config-status xmlns=“urn:mavenir:mavenir-config”>
<transaction-id>65</transaction-id>
<components>
<component-id>NFV30_VIM17-VDU_VLB22</component-id>
<result>SUCCESS</result>
<error-description><![CDATA[
<rpc-reply xmlns=“urn:ietf:params:xml:ns:netconf:base:1.0” message-id=“1”><ok/></rpc-reply>
]]></error-description>
</components>
</edit-config-status>
</notification>

leads to below exception when we try to parse the response
org.xml.sax.SAXParseException; lineNumber: 10; columnNumber: 4; The character sequence “]]>” must not appear in content unless used to mark the end of a CDATA section.
at com.tailf.jnc.YangXMLParser.parse(YangXMLParser.java:54)
at com.tailf.jnc.XMLParser.parse(XMLParser.java:154)

Any help would be greatly appreciated

Can you just escape the troublesome characters (e.g. using the method suggested here) before providing the data to JNC (and unescape after reading them back)? But since this looks like a JNC problem, you may want to ask for help on the JNC’s github page.

Thank you for the response. But this does not seem like a JNC problem. It looks most likely confd escaping unintentionally the CDATA section. JNC is the first point that receives the response so there isn’t a way we can escape before that. JNC just uses a standard XML parser to parse the response on the ssh session. Not sure if there is a bug already with confd on this issue , it can be easily reproduced by sending a CDATA section within the rpc .

Ok, looks like ConfD can behave better as far as encoding strings “looking like” a CDATA section is concerned. But then again, why do you store the error description string (is it a string, right?) with the CDATA markup, why don’t you store the string"<rpc-reply ..><ok/></rpc-reply>" just as is?

Hello,
XML within XML would be incorrect, it would make the XML invalid, hence it would be imperative to markup the value within the XML tag to be marked up with CDATA this would let XML parsers know that is the value and not the continuation of XML tag

But you are storing just a string, and when ConfD (or any other component) needs to take that string and use it in a XML document, it’s completely up to that component to escape whatever is needed to be escaped. If that string is sent over the wire inside a JSON document, again the component needs to make sure that the resulting JSON document is valid, but it’s not up to you to presume all possible future contexts in which your string appears - again, you are storing just a string. So there is no “XML within XML” from your point of view, or is it?

As a reference, the resulting escaped XML using for example https://www.freeformatter.com/xml-escape.htm :

&lt;edit-config-status xmlns=&quot;urn:mavenir:mavenir-config&quot;&gt;
     &lt;transaction-id&gt;65&lt;transaction-id&gt;
     &lt;components&gt;
       &lt;component-id&gt;NFV30_VIM17-VDU_VLB22&lt;/component-id&gt;
       &lt;result&gt;SUCCESS&lt;/result&gt;
       &lt;error-description&gt;&lt;![CDATA[
 &lt;rpc-reply xmlns=&quot;urn:ietf:params:xml:ns:netconf:base:1.0&quot; message-id=&quot;1&quot;&gt;&lt;ok/&gt;&lt;/rpc-reply&gt;
 ]]&gt;&lt;/error-description&gt;
    &lt;/components&gt;
  &lt;/edit-config-status&gt;
 &lt;/notification&gt;

Thanks for the reply. So are you suggesting not to include a CDATA explicitly in the response (error-description node) and Confd would take care (probably by adding a CDATA) of keeping the XML valid ?

I suggest you turn on the ConfD NETCONF trace log in confd.conf to find out.
Share your findings if you wish to be a good community citizen.
See confd.conf(5) man page under /confdConfig/logs/netconfTraceLog for details.