https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1202 controller <p>I have a netconf server which sent the RPC-reply begins and ends with new line character 0x0a as following message. sax exception will be thrown. I try to trim the message in the NetconfXMLToMessageDecoder.decode(), the exception disappears. </p> <p>0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 55 54 46 2d 38 22 3f 3e<br/> ...... <br/> 3c 2f 72 70 63 2d 72 65 70 6c 79 3e 0a</p> <p>Caused by: org.xml.sax.SAXParseException: The processing instruction target matching "<span class="error">&#91;xX&#93;</span><span class="error">&#91;mM&#93;</span><span class="error">&#91;lL&#93;</span>" is not allowed.<br/> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)<span class="error">&#91;:&#93;</span><br/> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)<span class="error">&#91;:&#93;</span><br/> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)<span class="error">&#91;:2.4.0&#93;</span><br/> at org.opendaylight.controller.netconf.util.xml.XmlUtil.readXmlToDocument(XmlUtil.java:99)<span class="error">&#91;191:org.opendaylight.controller.netconf-util:0.2.7.Helium-SR2&#93;</span><br/> at org.opendaylight.controller.netconf.nettyutil.handler.NetconfXMLToMessageDecoder.decode(NetconfXMLToMessageDecoder.java:29)<span class="error">&#91;199:org.opendaylight.controller.netconf-netty-util:0.2.7.Helium-SR2&#93;</span><br/> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:249)<span class="error">&#91;203:io.netty.codec:4.0.23.Final&#93;</span><br/> ... 15 more</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1202

netconf client can not parse RPC message begin with blank characters.

Bug Resolved Done Gwenael Lambrouin Bo Li Fri, 13 Mar 2015 09:48:28 +0000 Tue, 9 Jun 2015 10:12:34 +0000 Tue, 9 Jun 2015 10:12:34 +0000 Helium netconf 0 3 <p>I proposed a patch to fix this problem here:<br/> <a href="https://git.opendaylight.org/gerrit/16927" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/16927</a></p> <p>Please take bugs if you work on them (so we can keep track of the bugs). I assigned it to you for you this time.</p> <p>Also if you provide a fix and push into gerrit, set me as a reviewer just so I can see it in gerrit web UI.</p> <p>Thanks and Thanks for the patches</p> <p>As mentioned in gerrit, such XML is invalid and its expectad to fail during parsing. Have you tried finding a fix on the side of remote devices so that the devices do not return invalid XML ?</p> <p>I have test the netconf server with Netopeer,Mg-soft,Seguesoft netconf client. Both of them can communicate correctly.</p> <p>I don't think blank character before &lt;?xml means a invalid xml format. it should be a noise in transport. it is too strict for this check in ODL.</p> <p>I think it should be fixed from both side..</p> <p>I believe that it is invalid XML according to the XML specification. Thats why the standard java parser fails with exception. So before merging a fix into ODL codebase, the netconf devices should be checked.</p> <p>I am not against making it less strict in ODL, but it should be verified in the devices.</p> <p>Btw. I commented on proposed fix. Could you or Gwenael take a look at those in the meantime ?</p> <p>Thanks</p> <p>I made some unit tests of NetconfXMLToMessageDecoder.decode(), and I observed the following behaviour:</p> <ul> <li>when the message to decode does NOT start with a XML declaration (reminder: a "XML declaration" looks like "&lt;?xml version="1.0" encoding="UTF-8"?&gt;": leading white spaces are accepted by the parser.</li> <li>when the message to decode starts with a XML declaration: leading white spaces are rejected by the parser.</li> </ul> <p>This looks inconsistent, but in my understanding it is correct with respect to the XML 1.0 specifications (see <a href="http://www.w3.org/TR/REC-xml/#sec-well-formed" class="external-link" target="_blank" rel="nofollow noopener">http://www.w3.org/TR/REC-xml/#sec-well-formed</a> and <a href="http://www.w3.org/TR/REC-xml/#NT-prolog" class="external-link" target="_blank" rel="nofollow noopener">http://www.w3.org/TR/REC-xml/#NT-prolog</a>). So according to XML, I think that the ODL code is correct.</p> <p>I also looked at RFC 4742 (NETCONF over SSH). The examples are all nicely formatted with new lines and they include XML declarations. Unfortunately, there is no example with two consecutive messages. But in the spirit of that RFC, I think it is correct to have a new line just before an XML declaration at the beginning of a NETCONF message . This is really useful in interactive SSH sessions with a human being because it improves readability.</p> <p>Also, I made some tests with another network device that does not include XML declarations (a fairly recent Juniper router): the device starts its messages with a newline. This is accepted by ODL because there is not XML declaration.</p> <p>So I am now convinced that in the spirit of NETCONF, it is correct to accept messages coming with a leading newline and an XML declaration. So I think ODL should accept such messages.</p> <p>Now, I see three ways to fix the issue in ODL:<br/> 1. do the minimum to support the interoperability problems observed today: remove at most one line break at the beginning of the message: either LF (the case observed by Bo when he reported the bug) or CRLF (the case I observed with Cisco routers).<br/> 2. accept any number of XML white spaces (space, tab, CR, LF) at the beginning of the message (this is (almost) my initial proposal)<br/> 3. accept anything before the first '&lt;' character at the beginning of the message (this is Maros's proposal)</p> <p>Solution 1 is enough today, and it looks fine in the spirit of RFC 4742. However, the problem may resurface with a device that would eg start a messge with two line breaks.</p> <p>Solution 3 works fine and solves the problem. However, it looks excessive to me, because it would make ODL accept messages such as "slkdjf lsdkjf d&lt;hello/&gt;". While network device vendors do not use ODL as a reference NETCONF client to test their devices, this is not really a problem. But I think ODL should not do that.</p> <p>For me solution 2 provides a good balance between interop and strictness, and I still prefer this solution. But tell me what you think about it.</p> <p>In the meantime, I uploaded a new patchset that implements solution 3 (Maros code suggestion) and adds some unit tests:<br/> <a href="https://git.opendaylight.org/gerrit/16927" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/16927</a></p> Development External issue ID 2838 External issue URL ODL SR Target Milestone Rank 0|i02p47: