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

Question

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

EG

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

规范（https://www.jsonrpc.org/specification#request_object）没有提及添加其他字段的任何内容。

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

Answer 1

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

你是对的，因为Specification没有提到任何关于其他领域的事情。从法律上说，如果不是禁止的话，就是允许的。

另一方面，我在这里找到了至少一个参考实现：www.simple-is-better.org/rpc/jsonrpc.py，如果解码的消息包含额外的字段，它将会遇到异常。此代码来自JSON-RPC 2.0规范的作者之一RolandKö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 compat！）
• “Unaware”接收器：将静默或大声地抛出rpc.secinfo呼叫，但能够运行。缺少ID表示通知，即接收方不会根据JSON-RPC规范发回响应。
• “Unaware”发件人：收到的邮件是有效的，没有标头的邮件。

请随意重复使用此协议，但请注意这个SO答案。