0

クライアント側 JavaScript から XML-RPC サーバーとの通信を他の方法よりもはるかに簡単にする jQuery プラグインを作成しました。rtorrent クライアントと正常に通信する独自​​のアプリケーションで使用しました。スタンドアロン プラグインとして公開しました: jquery-xmlrpc

ユーザーはプラグインに対して 2 つの問題 ( #1と#2 ) をログに記録し、無効な XML-RPC の解析に失敗したと述べています。問題の無効な XML-RPC は空の<value>ノードです。ユーザーは、無効な XML-RPC ドキュメントを送信している XML-RPC サーバーを処理しています。<nil>、空の文字列、および不正な空の<value>ノードを含む、次の XML-RPC ドキュメントについて考えてみましょう。

<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 要素として扱ってよかったです。これは奇妙な特殊なケースのように見えましたが、扱いやすく、ロバストネス プリンシパルの精神に沿ったものでした。

「受け入れるものはリベラルに、
発信するものは保守的に」

RFC1122

しかしその後、問題が更新され<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 に答える