Open czeni opened 10 years ago
So, is this a bug in netconfd or a guidline for module developers? I've been away from netconf for a year, but I still have feelings for it :P
I guess both :), but i don't know the yuma well to tell whose responibility is that. However, i think this behavior is a serios flaw, because responding with an rpc-ok instead of rpc-error could mean a serious functional issue, so it should worth to deal with this. So i reported it, rewrote the library to use self-closing tags and from now use this workaround. I also reported this issue to the writers of the the third-party Java library.
Are you saying that <cancel-toast></cancel-toast>
returns rpc-ok but <cancel-toast/>
returns rpc-error?
Yes, if i don't call the make-toast method prior.
When messages sended to the netconfd are containing start/end XML tags instead of self-closing tags the netconfd processes these incorrectly. In my case i use a custom Java implementation for the client. I send a cancel-toast RPC to the loaded toaster module, although i don't requested a make-toast prior. So i should recieve an rpc-error message, but instead of i got an rpc-ok. Here is the XML messages which logged by the netconfd:
Request:
Reply:
According to the server log the netconfd processes this type of messages incorrectly and it actually invoke the server side cancel-toast RPC.
After i noticed this issue i correced and rewrote the third-party netconf library to use self closing tag. Then i got the expected rpc-error message.
And here is the server log (--log-level=debug3): https://gist.github.com/czeni/d7cfa79ffdae8508eefe