]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_ari.c: Prefer exact handler match over wildcard
authorGeorge Joseph <gjoseph@digium.com>
Tue, 20 Aug 2019 18:04:56 +0000 (12:04 -0600)
committerGeorge Joseph <gjoseph@digium.com>
Tue, 20 Aug 2019 18:19:42 +0000 (13:19 -0500)
commit8da4e28a81e46eb1e5be0702849e1304fce2764f
tree4d4afb770f4553e9603740ac860347b7454d6b30
parent15624d9a7af1424480aa9dab217d0c381fa12bd3
res_ari.c:  Prefer exact handler match over wildcard

Given the following request path and 2 handler paths...
Request: /channels/externalMedia
Handler: /channels/{channelId}      "wildcard"
Handler: /channels/externalmedia    "non-wildcard"

...if /channels/externalMedia was registered as a handler after
/channels/{channelId} as shown above, the request would automatically
match the wildcard handler and attempt to parse "externalMedia" into
the channelId variable which isn't what was intended.  It'd work
if the non-wildard entry was defined in rest-api/api-docs/channels.json
before the wildcard entry but that makes the json files
order-dependent which isn't a good thing.

To combat this issue, the search loop saves any wildcard match but
continues looking for exact matches at the same level.  If it finds
one, it's used.  If it hasn't found an exact match at the end of
the current level, the wildcard is used.  Regardless, after
searching the current level, the wildcard is cleared so it won't
accidentally match for a different object or a higher level.

BTW, it's currently not possible for more than 1 wildcard entry
to be defined for a level.  For instance, there couldn't be:
Handler: /channels/{channelId}
Handler: /channels/{channelName}
We wouldn't know which one to match.

Change-Id: I574aa3cbe4249c92c30f74b9b40e750e9002f925
res/res_ari.c