[NETCONF-904] Data sent via yang-patch is validated in a different way than PUT / POST Created: 07/Oct/22 Updated: 24/Nov/22 Resolved: 24/Nov/22 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | restconf-nb |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.11 |
| Type: | Bug | Priority: | Medium |
| Reporter: | Lena Peuker | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Data that is sent via yang-patch is validated in a different way than sending it via simple PUT/POST request:
{
"ietf-restconf:yang-patch": {
"patch-id": "patch-1",
"edit": [
{
"edit-id": "edit1",
"operation": "replace",
"target": "/",
"value": {
<config>
}
}
]
}
}
Opendaylight returns following error when data is sent via yang-patch:
{
"errors": {
"error": [
{
"error-type": "protocol",
"error-tag": "malformed-message",
"error-message": "Error parsing json input: Expected BEGIN_OBJECT but was NUMBER at line 22 column 63 path $.ietf-restconf:yang-patch.edit[0].value.<...>",
"error-info": "Expected BEGIN_OBJECT but was NUMBER at line 22 column 63 path $.ietf-restconf:yang-patch.edit[0].value.data[0].<...>"
}
]
}
}
For yang-patch all NUMBERS / BOOLEAN-values needs to be converted in order that it is acceppted from Opendaylight. "Simple" PUT / POST request accepts different types of values (number / boolean). |
| Comments |
| Comment by Ivan Hrasko [ 12/Oct/22 ] |
Expected BEGIN_OBJECT but was NUMBER at line 22 column 63 But the input is too short, it does not contain line 22. Can you please provide us with example of successful PUT/POST and unsuccessful PATCH with the same values/data? |
| Comment by Arne Chrestin [ 21/Nov/22 ] |
|
Example using the o-ran-delay-management module of the O-RAN simulator: PUT {
"o-ran-delay-management:delay-management": {
"adaptive-delay-configuration": {
"bandwidth-scs-delay-state": [
{
"bandwidth": 3000,
"subcarrier-spacing": 20,
"o-du-delay-profile": {
"tx-max": 100,
"ta4-max": 100,
"t1a-max-up": 100,
"rx-max": 100,
"t1a-max-cp-dl": 100
}
}
]
}
}
}
Corresponding PATCH {
"ietf-restconf:yang-patch": {
"patch-id": "patch-1",
"edit": [
{
"edit-id": "edit1",
"operation": "merge",
"target": "/o-ran-delay-management:delay-management/o-ran-delay-management:adaptive-delay-configuration",
"value": {
"adaptive-delay-configuration": {
"bandwidth-scs-delay-state": [
{
"bandwidth": 3000,
"subcarrier-spacing": 20,
"o-du-delay-profile": {
"tx-max": 100,
"ta4-max": 100,
"t1a-max-up": 100,
"rx-max": 100,
"t1a-max-cp-dl": 200
}
}
]
}
}
}
]
}
}
error message: {
"errors": {
"error": [
{
"error-type": "protocol",
"error-tag": "malformed-message",
"error-message": "Error parsing json input: Expected BEGIN_OBJECT but was NUMBER at line 13 column 50 path $.ietf-restconf:yang-patch.edit[0].value.adaptive-delay-configuration.bandwidth-scs-delay-state[0].bandwidth",
"error-info": "Expected BEGIN_OBJECT but was NUMBER at line 13 column 50 path $.ietf-restconf:yang-patch.edit[0].value.adaptive-delay-configuration.bandwidth-scs-delay-state[0].bandwidth"
}
]
}
}
If all numerical values are submitted as strings (e.g. "bandwidth: "3000"), the PATCH request is executed. |
| Comment by Ivan Hrasko [ 22/Nov/22 ] |
|
Thanks! |
| Comment by Ivan Hrasko [ 23/Nov/22 ] |
|
achrestin You are using tow different versions of RESTCONF. With rests/data you are using RFC8040 version what is better for you With restconf/config you are using bierman-02 version - which is deprecated and in recent ODL version removed. Please use /rests/data/network-topology:network-topology/topology=topology-netconf/node=nts-ng-sim/yang-ext:mount as URI in your PATCH request and everything will be ok. |
| Comment by Arne Chrestin [ 23/Nov/22 ] |
|
Thanks for the clarification! Just a small addition: It seems that for the bierman-02 version, the Content-Type header field must be set to "application/yang.patch+json", while it must be "application/yang-patch+json" for the RFC8040 version. |
| Comment by Robert Varga [ 23/Nov/22 ] |
|
Yes, RFC8040 follows RFC8072, bierman02 follows draft-ietf-netconf-patch-XX, where XX is a number I do not remember. The evolution of media types is evident in the draft changelog . |
| Comment by Ivan Hrasko [ 24/Nov/22 ] |
|
Please use the same version of RESTCONF when you expect the same results. |
| Comment by Ivan Hrasko [ 24/Nov/22 ] |
|
It looks there is no bug. |