[CONTROLLER-311] Strings with certain special characters in JSON cause RESTCONF to return 400 Bad Request Created: 14/Apr/14  Updated: 25/Jul/23  Resolved: 16/Oct/14

Status: Resolved
Project: controller
Component/s: restconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Zoltan Lajos Kis Assignee: Jozef Gloncak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 720

 Description   

I have a config datastore model in yang, which contains a string field.

When I try to push a new entry via Restconf using JSON, if this string has a colon in it, it gets rewritten. For example, if my original string is "openflow:21", what appears in the datastore is "[openflow - 21]".

When using XML, this does not happen; the original string appears in the datastore.



 Comments   
Comment by Jozef Gloncak [ 23/Apr/14 ]

Which is YANG type for "openflow:21"? (leafref?)
What is the module name of YANG file where this leaf is present?
Is this beheviour seen for every leaf YANG type?

Comment by Zoltan Lajos Kis [ 23/Apr/14 ]

That is just a simple string type leaf in any container. Define the following simple config model for your bundle:

grouping mydata {
leaf id

{ type uint64; }

leaf data

{ type string; }

}

container mycontainer {
list data

{ uses mydata; key "id"; }

}

Then try to add an element to this container via restconf, using JSON encoding, where the data string is "openflow:21".

What I see in this case is that the POST is successful, but when I try to read back the data (either via restconf, or via the databrokerservice), the string contents turn into "[openflow - 21]".

Comment by Jozef Gloncak [ 24/Apr/14 ]

If input string contained colon ( then it was dealed as namespace:value
and object of type IdentityValuesDTO was created (it is probable that
data could be of type identityref). If data wasn't of type leafref then it
was incorrectly processed as leafref.
The RestCodec was updated to correctly translate data (cases when data
contains ':' but aren't of type leafref)

https://git.opendaylight.org/gerrit/#/c/6335/

Comment by Jozef Gloncak [ 30/Apr/14 ]

Merged on 28APR2014

Comment by Colin Dixon [ 25/Sep/14 ]

So, it turns out it's not just a colon. I can reproduce this in the latest Helium build as long as the string contains an open angle bracket (<) and a colon ( with the angle bracket coming before the colon.

I found this originally by testing this snippet (which I got from the ONF spec for TTPs) against the TTP project at the URL:
http://localhost:8181/restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/

{
"table-type-patterns": {
"table-type-pattern": [
{
"identifiers": [

{ "doc": [ "The VLAN ID of a locally attached L2 subnet on a Router." ], "var": "<subnet_VID>" }

,

{ "doc": [ "An OpenFlow group identifier (integer) identifying a group table entry", "of the type indicated by the variable name" ], "var": "<<group_entry_types:name>>" }

]
}
]
}
}

The key line is:
"var": "<<group_entry_types:name>>"

Things that fail:
"var": "<<group_entry_types:name>>"
"var": "<group_entry_types:name>>"
"var": "<groupentrytypes:name>>"
"var": "<groupentrytypes:name"
"var": "groupentryt<ypes:name"

Things that succeed:
"var": "groupentrytypes:name>>"
"var": "<<groupentrytypes/name>>"
"var": "groupentrytypes:na<me"

I'm just running the most recent Helium karaf distro and then running this in install the relevant features:
feature:install standard odl-restconf odl-mdsal-broker odl-mdsal-apidocs odl-ttp-all

Comment by Colin Dixon [ 25/Sep/14 ]

The error I get back is:

{
"errors": {
"error": [

{ "error-type": "protocol", "error-tag": "malformed-message", "error-message": "Error parsing input: Illegal character in path at index 0: <<groupentrytypes" }

]
}
}

Comment by Jozef Gloncak [ 25/Sep/14 ]

should be fixed
https://git.opendaylight.org/gerrit/11566

Comment by Jozef Gloncak [ 14/Oct/14 ]

The direct e-mail was sent to Giovanni Meo. It was asked for fix merging.

Comment by Jozef Gloncak [ 16/Oct/14 ]

merged on 15. october 2014

Generated at Wed Feb 07 19:52:43 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.