Operating System: Linux
Platform: PC

I am able to replicate this bug and working to debug the same

Hi,

I am able to replicate the bug by following the below mentioned steps:

PUT : http://192.168.56.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/22/

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<priority>2</priority>
<flow-name>Foo</flow-name>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.10.2/24</ipv4-destination>
</match>
<id>22/</id>
<table_id>1</table_id>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<dec-nw-ttl/>
</action>
</apply-actions>
</instruction>
</instructions>
</flow>

The flow gets created and RESPONSE is 200 ok.

When I hit the below URI it fails to generate the xml.

GET : http://192.168.56.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/22/

Following are my observations:

1.) pathArgs array is created by slicing the above URI based on "/" delimiter.

ControllerContext.java

public InstanceIdWithSchemaNode toInstanceIdentifier(final String restconfInstance) {
this.checkPreconditions();
final String[] pathArgs = restconfInstance.split("/");
boolean _isEmpty = ((List<String>)Conversions.doWrapArray(pathArgs)).isEmpty();
if (_isEmpty)

So the logic understands flow ID - "22/" as "22" while fetching value from the URI.
But the PUT body still contains flow ID as "22/" which creates a conflict and a proper flow entry is not created.

2.) The logic can be augmented to allow users to create and retrieve flow with flow ID "22/" in URI, while the created flow in DB will still be of ID 22, thus enabling the user to get proper xml.

Request you to please confirm if this is the expected implementation.

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

logic has been augmented to allow users to create and retrieve flows having "/" in flow ID. The user gets a proper xml while retrieving the flow.

Thanks
Priyanka

Priyanka Chopra:
Restconf specification states that if the "/" slash is part of key, to distinguish it from separator must be URL-encoded to %2f.

This bug also deeps down more, because tomcat does not allow %2f in URL or deecodes them to "/" so restconf does not get original view of URI supplied by the user.

This requires further investigation in Jersey and Tomcat configuration in container, to find right combination when escaping will get passed to the restconf.

Hi Tony,

We can configure the server to allow encoded characters in origin. Although only doing this will not fix CONTROLLER-130 as the pathArgs array is created by slicing the URI based on "/" delimiter and hence the "/" will again be ignored by the code.

Have attached the snippet below:
ControllerContext.java

public InstanceIdWithSchemaNode toInstanceIdentifier(final String restconfInstance) {
this.checkPreconditions();
final String[] pathArgs = restconfInstance.split("/");
boolean _isEmpty = ((List<String>)Conversions.doWrapArray(pathArgs)).isEmpty();
if (_isEmpty)

Moreover this bug is closely related with CONTROLLER-148.

Thanks
Priyanka

The patch which should solve this issue was commited
https://git.opendaylight.org/gerrit/#/c/5368/

It also is necessary to insert line
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
to config.ini file which is part of distribution package. This setting allows inserting of %2F char sequences to URI.

It was also necessary to use @Encoded anotation before method parameters which should hold identifier in RestconfService.java interface. The annotation disables automatic decoding of specific characters from URI. So it is possible to resolve %2F in methods of RestconfService interface.

Example
Assume path which consist of list >lst< with key >ke/y<.
The URI which makes it possible to access data behind this key is
http://server/lst/ke%2Fy

commit was merged