[CONTROLLER-559] RPC with malformed JSON data picks ad-hoc interpretation instead of error code 400.

Tue, 14 Nov 2017 15:18:01 +0000

This bug uses data from ~~CONTROLLER-333~~ now with knowledge it is malformed. Original comment:

Hi.
I have tried creating curl command using JSON data
that would create tunnel with explicit path.
This is XML data version which works ok:
curl -X POST -H "Content-Type:application/yang.data+xml" -d '<input><node>pcc://39.39.39.39</node><name>odveci</name><network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref><arguments><endpoints-obj><ipv4><source-ipv4-address>39.39.39.39</source-ipv4-address><destination-ipv4-address>43.43.43.43</destination-ipv4-address></ipv4></endpoints-obj><ero><subobject><loose>false</loose><ip-prefix><ip-prefix>195.20.160.40/32</ip-prefix></ip-prefix></subobject><subobject><loose>false</loose><ip-prefix><ip-prefix>201.20.160.43/32</ip-prefix></ip-prefix></subobject><subobject><loose>false</loose><ip-prefix><ip-prefix>43.43.43.43/32</ip-prefix></ip-prefix></subobject></ero></arguments></input>' 127.0.0.1:8080/restconf/operations/network-topology-pcep:add-lsp
and this is JSON version which almost works:
curl -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"odveci","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]","arguments":{"endpoints-obj":{"ipv4":{"source-ipv4-address":"39.39.39.39","destination-ipv4-address":"43.43.43.43"}},"ero":[{"subobject":{"loose":false,"ip-prefix":

{"ip-prefix":"195.20.160.40/32"}

}},{"subobject":{"loose":false,"ip-prefix":

{"ip-prefix":"201.20.160.43/32"}

}},{"subobject":{"loose":false,"ip-prefix":

{"ip-prefix":"43.43.43.43/32"}

}}]}}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:add-lsp
but in this case created tunnel only has
one of 3 hops, the first one to 195.20.160.40.
Is this a known issue?

What is malformed:
grouping explicit-route-object contains
container ero {
...omitted....
list subobject

{ ...omitted... }

...omitted...
}
So conclusion is that YANG element has to be mapped to JSON:

container -> "container_name":{}
list -> "list_name":[{},{},...{}]

I would expect to get error code 400 when submitting "container_name":[...] or "list_name":

{<fields>}

as silent reinterpretation leads to confusing behavior (only first hop present in resulting path).

OpenDaylight JIRA

[CONTROLLER-559] RPC with malformed JSON data picks ad-hoc interpretation instead of error code 400.