JSON RPC 2.0：请求对象上的额外字段是不是违反规范？

Posted 2023-02-16

【中文标题】JSON RPC 2.0：请求对象上的额外字段是不是违反规范？

【英文标题】：JSON RPC 2.0: Do Extra Fields on Request Objects Violate Specification?JSON RPC 2.0：请求对象上的额外字段是否违反规范？

【发布时间】：2019-03-09 17:51:50

【问题描述】：

我正在编写一个符合 JSON RPC 的 js 库。规范是否允许客户端将自定义字段（例如 headers）沿 params 字段添加到 Request 对象？

例如

"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "headers":  "original-client": 12 , "id": 1

规范 (https://www.jsonrpc.org/specification#request_object) 没有提及任何关于添加额外字段的内容。

如果我的库添加了header 字段，是否违反规范？

【参考方案1】：

这里有同样的问题。 （我想添加用户身份验证信息/消息签名...）

您是对的，Specification 没有提及任何有关其他字段的内容。所以从法律上讲，如果不禁止，就是允许的。

另一方面，我在这里找到了至少一个参考实现：www.simple-is-better.org/rpc/jsonrpc.py，如果解码的消息包含额外的字段，它会抛出异常。此代码来自 JSON-RPC 2.0 规范的作者之一，Roland Köbler。

所以，YMMV。

如果您的库只是专有系统的内部构建块，请继续。 如果您需要与其他 JSON-RPC 实现交互，请分别测试。 如果图书馆打算供公众使用，请不要这样做。

编辑：我使用以下协议解决了这个问题：

在“有效负载”消息之前，使用方法"rpc.secinfo" 发送符合标准的通知。 （rpc. 前缀按规范保留用于扩展） "params" 字段包含任何适用的元数据（例如用户名、签名） 示例："jsonrpc": "2.0", "method": "rpc.secinfo", "params": "user":"root", "signature":"0xDEADBEEF"<DELIM><payload><DELIM> 如果标头数据为空，则不假装特殊方法（即行为与标准 json-rpc 完全相同）。

接收者可以像任何其他调用一样对标头消息进行解码，只需将标头应用（检查 sig 等）到以下消息。

讨论：

允许在不接触有效负载的情况下进行分帧 允许在不解码负载的情况下解码标头 允许按原样使用字节有效负载，特别是允许加密+文字有效负载共存（但是加密有效负载破坏了 JSON-RPC 兼容性！） “无意识”接收器：将 rpc.secinfo 呼叫以静默或响亮的方式丢弃，但能够运行。缺少 ID 表示通知，即接收方不会根据 JSON-RPC 规范发回响应。 “不知道”发件人：收到的消息是有效的、无标头的消息。

请随意重用此协议，但请注明此 SO 答案。

【讨论】：

谢谢！我已经决定不包含标题，而只使用前缀参数字段。然而，这对于期望 params 是一个数组的实现是有问题的......

用我确定的解决方案扩展了答案。