]> 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:02 +0000 (13:19 -0500)
commitf82d0b74fd870b94609c196c11bdc9c4d5b9663b
tree13898e078bb6b6190dd8ab8d41e842a89a25f060
parentff180a5bfc3090485ee7b2746ce7bee58e754746
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