JSONRPCS replacing keys in params gives unexpected behaivor

[ovoshlook]

Hi
Using kamailio with http jsonrpcs
found next trouble

When i make request like

curl -s -H 'Content-Type: application/json' --data-binary '{"method":"htable.get","params":{"name":"mytable","key":"myparam"},"jsonrpc":"2.0"}' http://127.0.0.1:5060/jsonrpc

all fine. I getting good response

But when I making
curl -s -H 'Content-Type: application/json' --data-binary '{"method":"htable.get","params":{"key":"myparam","name":"mytable"},"jsonrpc":"2.0"}' http://127.0.0.1:5060/jsonrpc
i.e keys of object on different positions

It gives me

curl -s -H 'Content-Type: application/json' --data-binary '{"jsonrpc":"2.0", "method": "htable.get","params":{"key":"mykey","name": "mytable"}}' http://127.0.0.1:5060/jsonrpc
{
"jsonrpc": "2.0",
"error": {
"code": 500,
"message": "No such htable"
}
}

Means kamailio cant find needed htable

I supposed that position of the key should't have a matter for the JSON objects parsers
But here is looks like different

May be it is not a bug bug feature request because of it is just an unexpected behaivor

Im using kamailio 5.1.3 on the Debian 9

version: kamailio 5.1.3 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 00:25:48 May 9 2018 with gcc 6.3.0

[miconda]

The RPC interface is designed for positional parameters, not named parameters, in other words, the order is important. For example binrpc (implemented by ctl and used by kamcmd) doesn't have a way to give names for params, and, iirc, xmlrpc (initial) specs were also with positional params. If you look at the docs for rpc commands, they do not define names for parameters.

The jsonrpcs ignore the names and use the values based on position.

I am closing this one, even a feature request is something that needs a lot of work in couple of modules. of course, a pull request with such enhancement will be considered, but it is out of scope to keep it as a feature request.