Summary:	ASTERISK-24284: ARI fails to strip whitespace properly on bridge type attribute, allowing for bridges to be created even when provided attribute types conflict
Reporter:	Pavel Kukin (pavelsc)	Labels:
Date Opened:	2014-08-28 18:17:27	Date Closed:	2014-10-20 16:52:06
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari_bridges
Versions:	12.5.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	Bridge create query {noformat} curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,holding,dtmf_events,proxy_media" {noformat} returns 500 error. When type param contains spaces, it works. {noformat} curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media" {noformat} Returned data is: {noformat} {"id":"16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d","channels":[],"name":"","technology":"simple_bridge","bridge_class":"stasis","creator":"Stasis","bridge_type":"mixing"} {noformat} As you can see type contains only mixing param and this is incorrect behavior. But at least it works. When I am using the same parameters separated with commas and spaces in my ari client code it returns 500 error. Weird thing. In previous Asterisk version my client had the same code and here is example how it worked. Request: {noformat} { type: 'mixing, holding, dtmf_events, proxy_media',  bridgeId: 'b1cc1a44-0091-49db-ad62-97d165d70c05' } {noformat} Response: {noformat} {"id":"b1cc1a44-0091-49db-ad62-97d165d70c05","channels":[],"name":"","technology":"holding_bridge","bridge_class":"base","creator":"Stasis","bridge_type":"holding"} {noformat} Returned body had only holding type, which is also wrong. Another weird thing. I think the new ARI has some errors in its param parser.
Comments:	By: Richard Mudgett (rmudgett) 2014-08-28 19:46:28.523-0500 A bridge can be either holding or mixing.  It cannot be both. By: Matt Jordan (mjordan) 2014-08-28 20:49:34.724-0500 To provide more context to what Richard said: What you are specifying when you provide a {{type}} to the bridge are attributes that you want the mixing technology to have: {quote} type: string - Comma separated list of bridge type attributes (mixing, holding, dtmf_events, proxy_media). {quote} That doesn't mean that the bridge handed back to you is going to have everything you list. It isn't. In fact, providing all of the attributes doesn't make any sense: * A {{mixing}} attribute - which asks that media be mixed between all participants - is contradictory with a {{holding}} attribute * A {{dtmf_events}} attribute - which asks Asterisk to decode all media so it can interpret DTMF - is contradictory with {{proxy_media}}, which asks Asterisk to natively swap media packets between channel drivers, if it can do so I'll admit the wiki needs some more documentation on this front, but that's something we are actively working on (as you can probably tell by the recent updates on the wiki). A bridge mixing technology that is returned in the resulting JSON is what Asterisk decided was the *best* mixing technology based on the attributes that you provided it. If you provide it with a bunch of attributes that don't make sense together, it does the best it can. Which is to give you a basic mixing technology (most likely with the media being decoded internally) if it can; or to return back a 500 if what you gave it makes no sense whatsoever. Note that the spaces have nothing to do with you getting a 500. If I use a valid combination of attributes: {noformat} curl -v -u "asterisk":"asterisk" -X POST "http://localhost:8088/ari/bridges?brigeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,dtmf_events" {noformat} Asterisk happily creates a bridge: {noformat} < HTTP/1.1 200 OK < Server: Asterisk/SVN-trunk-r422257 < Date: Fri, 29 Aug 2014 01:44:03 GMT < Cache-Control: no-cache, no-store < Content-type: application/json < Content-Length: 193 < {  "id": "16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d",  "technology": "simple_bridge",  "bridge_type": "mixing",  "bridge_class": "stasis",  "creator": "Stasis",  "name": "",  "channels": [] } {noformat} The reason you get a 500 is because Asterisk explicitly forbids combining the {{holding}} and {{mixing}} attributes. The only issue here is that using 'spaces' pre-pending the attributes caused it to work. We are using {{ast_strip}} to pull off leading whitespace characters; however, that doesn't appear to be working as intended. By: Pavel Kukin (pavelsc) 2014-08-29 19:26:05.395-0500 Richard, Matt thank you guys a lot for clarifying these points to me. Now it works. By: Jonathan Rose (jrose) 2014-10-20 16:25:37.253-0500 This is actually already problematic by the time it gets into httpd_process_request. I don't believe spaces are actually permitted in this at all. I ran: curl -v -u "admin":"secret" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media" and broke in httpd_process_request immediately after request_line is read from ser->f to see what the request_line looked like and it looked like this: "POST /ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media HTTP/1.1\r\n", '\000' <repeats 2639 times>"\224, ٣\270\250\177", '\000' <repeats 18 times>, "\003\000\000\000\000\000\000\000\060\001\272\001\000\000\000\000\n\356\273b\000\000\000\000\236⣸\250\177\000\000\000\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\240\030HI\250\177\000\000\377\377\377\377\000\000\000\000\070\225/s\250\177\000\000\220"... and since space is used to delimit the type arguments from the HTTP version, I can only think that it just isn't appropriate to try to separate by spaces in the first place. Ultimately this arrives in ARI with params looking like type = "holding," and everything after that first space is gone entirely. I'll wait for some commentary, but my opinion right now is that there isn't any bug here. By: Jonathan Rose (jrose) 2014-10-20 16:51:50.147-0500 Richard informed me that you can escape spaces in request strings like that by using + characters as spaces.  I tested this and it's true. With that in mind, I'm closing the issue.