08-22-2022 11:52 AM
NSO Version 5.5.4.1
Sending restconf call with special chars in it returns 404.
show l3vpn-interface LABDEVICE 1111:1111:111:1fff:1111::/128 | display restconf
/restconf/data/l3vpn-interface:l3vpn-interface=LABDEVICE,1111%3A1111%3A111%3A1fff%3A1111%3A%3A%2F128
{
"ietf-restconf:errors": {
"error": [
{
"error-type": "application",
"error-tag": "invalid-value",
"error-message": "uri keypath not found"
}
]
}
}Does NSO require a special syntax for restconf URI characters? Per the RFC this should be a valid path
The following example shows how reserved characters are
percent-encoded within a key value. The value of "key1" contains
a comma, single-quote, double-quote, colon, double-quote, space,
and forward slash (,'":" /). Note that double-quote is not a
reserved character and does not need to be percent-encoded. The
value of "key2" is the empty string, and the value of "key3" is the
string "foo".
Example URL:
/restconf/data/example-top:top/list1=%2C%27"%3A"%20%2F,,foo
Solved! Go to Solution.
08-24-2022 06:33 AM - edited 08-24-2022 06:34 AM
Turned out this was due to the Nginx proxy that was decoding the URI before sending to NSO. I had to add some rewrite statements to Nginx to tell it to not decode the URI and send it as is to NSO.
#Server Location
rewrite ^ $request_uri;
rewrite ^/(.*) $1 break;
return 400;
proxy_pass http://127.0.0.1:8080/$uri;
proxy_request_buffering off;
proxy_read_timeout 90;
08-24-2022 01:47 AM
How does your call look? Copying the path from NSOs display restconf should work. I was able to make the RESTCONF call with the following model:
list example-list {
key "name address";
leaf name {
type string;
}
leaf address {
type inet:ipv6-prefix;
}
leaf example-leaf {
type string;
}
}
Which resulted in the following:
curl -u admin:admin http://localhost:8080/restconf/data/test-service:example-list=test-name,1111%3A1111%3A111%3A1fff%3A1111%3A%3A%2F128 -H "Accept: application/yang-data+json"
{
"test-service:example-list": [
{
"name": "test-name",
"address": "1111:1111:111:1fff:1111::/128",
"example-leaf": "randomdata"
}
]
}
08-24-2022 06:06 AM
Instance
admin@labncs# show running-config l3vpn-interface LABDEVICE 2607:f440:300:11ff:1111::/128 | display restconf
/restconf/data/l3vpn-interface:l3vpn-interface=LABDEVICE,2607%3Af440%3A300%3A11ff%3A1111%3A%3A%2F128➜ ~ curl -u admin:admin https://ncslab.localhost/restconf/data/l3vpn-interface:l3vpn-interface=LABDEVICE,2607%3Af440%3A300%3A11ff%3A1111%3A%3A%2F128
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-message>uri keypath not found</error-message>
</error>
</errors>
➜ ~
08-24-2022 06:13 AM
After seeing that it worked I tested again and noticed that it was our HTTP proxy nginx configuration that is breaking this. If I turn off nginx and go directly to NSO it works fine.
08-24-2022 06:33 AM - edited 08-24-2022 06:34 AM
Turned out this was due to the Nginx proxy that was decoding the URI before sending to NSO. I had to add some rewrite statements to Nginx to tell it to not decode the URI and send it as is to NSO.
#Server Location
rewrite ^ $request_uri;
rewrite ^/(.*) $1 break;
return 400;
proxy_pass http://127.0.0.1:8080/$uri;
proxy_request_buffering off;
proxy_read_timeout 90;
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide