I have written a jQuery plugin that makes communicating with XML-RPC servers from client side JavaScript much easier than it would otherwise be. I have used it in an application of my own where is successfully communicates with an rtorrent client. I published it as a stand alone plugin: jquery-xmlrpc
A user has made logged two issues (#1 and #2) against the plugin, stating that it fails to parse invalid XML-RPC. The invalid XML-RPC in question is empty <value> nodes. The user is dealing with an XML-RPC server that is sending invalid XML-RPC documents. Consider the following XML-RPC document, containing a <nil>, empty string, and an incorrect empty <value> node:
<struct>
<member>
<!-- A null value -->
<name>nilElement</name>
<value><nil /></value>
</member>
<member>
<!-- An empty string -->
<name>emptyString</name>
<value><string></string></value>
</member>
<member>
<!-- Invalid XML-RPC -->
<name>badEmptyValue</name>
<value></value>
</member>
</struct>
Initially, I was happy to handle incorrectly empty <value> nodes, and treat them as <nil/>/null elements. This seemed an odd corner case, but one that was easy to handle, and kept within the spirit of the Robustness Principal:
"Be liberal in what you accept, and
conservative in what you send"
But then the issue was updated to say that the badly behaving server also sent raw strings in <value> nodes, as follows:
<!-- Correct string encoding -->
<value><string>Hello, World!</string></value>
<!-- Incorrect string encoding -->
<value>Raw, incorrect string</value>
At this point, the remote server is just plain incorrect. This is not valid XML-RPC at all. But the Robustness Principal states that I should be liberal in what I accept.
How far should the Robustness Principal be taken? Should I accept raw strings? Should I refuse, telling the other user to log a bug against the badly behaving XML-RPC server? At which point does accepting bad input go too far?
