我的XML-RPC插件的穩健性

我寫了一個jQuery插件，它使得與來自客戶端JavaScript的XML-RPC服務器進行通信比其他方式更容易。我已經在一個自己的應用程序中使用它，它可以與一個客戶端成功進行通信。我發表它作爲一個單獨的插件：jquery-xmlrpc 我的XML-RPC插件的穩健性

的用戶已作出登錄兩個問題（#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服務器的錯誤嗎？在哪一點接受糟糕的投入會變得太過分？

來源

2013-01-21 Tim Heap

實際上，XML-RPC規範說，沒有子元素的<value>節點應該被視爲字符串節點。我一定錯過了那部分。在這種情況下的正確答案是符合規範並正確處理<value>節點中的字符串。

來源

2013-01-22 00:08:25

我的XML-RPC插件的穩健性

回答

相關問題