0

我编写了一个 jQuery 插件，它使从客户端 JavaScript 与 XML-RPC 服务器的通信比其他方式更容易。我已经在我自己的应用程序中使用了它，它可以与 rtorrent 客户端成功通信。我将它作为独立插件发布：jquery-xmlrpc

用户已针对插件记录了两个问题（#1和#2），指出它无法解析无效的 XML-RPC。有问题的无效 XML-RPC 是空<value>节点。用户正在处理发送无效 XML-RPC 文档的 XML-RPC 服务器。考虑以下 XML-RPC 文档，其中包含一个<nil>空字符串和一个不正确的空<value>节点：

<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>

最初，我很乐意处理错误的空<value>节点，并将它们视为<nil/>/null 元素。这似乎是一个奇怪的极端案例，但很容易处理，并且符合鲁棒性原则的精神：

“在你接受的东西上要自由，
在你发送的东西上要保守”

RFC 1122

但随后问题被更新为表现不佳的服务器也在<value>节点中发送了原始字符串，如下所示：

<!-- Correct string encoding -->
<value><string>Hello, World!</string></value>

<!-- Incorrect string encoding -->
<value>Raw, incorrect string</value>

在这一点上，远程服务器完全不正确。这根本不是有效的 XML-RPC。但是鲁棒性原则指出，我应该在我接受的东西上保持自由。

鲁棒性原则应该走多远？我应该接受原始字符串吗？我是否应该拒绝，告诉其他用户针对表现不佳的 XML-RPC 服务器记录一个错误？在什么时候接受错误的输入会走得太远？

4

1 回答 1

0

实际上，XML-RPC 规范说<value>没有子元素的节点应该被视为字符串节点。我一定错过了那个部分。在这种情况下，正确的答案是符合规范并正确处理<value>节点中的字符串。

于 2013-01-22T00:08:25.590 回答