Proper URL decoding for resource name

[ismailhabib]

At this moment, having an URL encoded resource name which contains '/' will confuse the module into thinking that it refer to another path

[mweststrate]

Hi Habib,

Can you describe your exact test case?

If you directly use a '/' in your url, this is currently on purpose, because othwerise it might be quickly confusing; a path like groups/17/users/13 might either refer to group 17 user 13, or just group 17/users/13. That behaviour can be altered but the orderof service definition becomes very important in that case. Would you like to see this changed? But indeed it should then become possible to name a group 17/users/13 and still refer to a user inside that group by using groups/17/users/13/users/13, which would be a confusing yet valid case.

Note that you won't be able to match group 17 with user 13/users/13 in that case, because paths become ambigious and the first matching rule will be used.

Or is your current usecase groups/17%2fusers%2f/users/13? because that should work correctly indeed.

[ismailhabib]

Hi Michel,

It's the latter case. I'm using an OpenID as a resource name. Since typically OpenID contains several slashes, I encoded the value beforehand, still according to the error message, the path is not found. I can post a more detailed case on Monday.

[ismailhabib]

Request URL:

/api/1/users/https%3A%2F%2Fmxid2.mendix.dev%2Fmxid2%2Fid%3Fid%3Df3ecda3f-1cd4-4571-92d9-5c53bd80c542/

Response:

{
    "message": "Unknown service: '1'",
    "error": "NOT_FOUND: PUT 1/users/https:/mxid2.mendix.dev/mxid2/id%3fid=f3ecda3f-1cd4-4571-92d9-5c53bd80c542/",
    "status": 404
}

[dlhartveld]

Implemented in v1.3.0-rc2.