[FEATURE] improve sigmesgops->has_body_part description

[securepii-dev]

I was trying to use has_body_part to identify a dtmf-relay INFO message and getting strange results where it would always pass no matter what content type it was.
I realised after reading the code that has_body_part only matches against the defined list of MIME types and silently allows application/* to match.

It would be nice to put dtmf-relay into the static list but I understand that there is only a finite number of entries on that list.

At a minimum, improve the has_body_part documentation to note that only the static list of MIME types is matched and unknown application types match the SUBTYPE_UNKNOWN.
Useful as well to note that $cT =~ "^application/dtmf-relay" as a pattern is a valid alternative (if that is true)

[bogdan-iancu]

Hi @securepii-dev , indeed, for unsupported TYPEs and SUBTYPEs, the TYPE_UNKNOWN/SUBTYPE_UNKNOWN will be considered (after parting the mime). In your case, for application/dtmf-relay, it will be parsed into TYPE_APPLICATION/SUBTYPE_UNKNOWN.

But IMHO, using has_body_part is not the best approach here, as you do not have a multi-part body, so you just complicate the things :). Testing the $hdr(Content-Type) as string will simply work (similar to $cT).

Nevertheless, the point you maid is valid a [SUB]TYPE_UNKNOWN (either in the msg, either as func param) will simply match any other kind of mime/submime. Meaning has_body_part("application/dtmf-relay") will return true for Content-type: application/sdp....which, indeed, is kind of broken....

Not sure if this is a documentation issue, maybe more a bug, IMHO

[securepii-dev]

Hi Bogdan,
Is it a bug? I certainly found it unexpected but reading the code I understand why it has been coded that way. The integer compare is so much faster. That is why I suggested a documentation update to make it clear rather than having to dig into the code.

If it should be fixed, maybe make any [SUB]TYPE_UNKNOWN just not match at all, i.e. always fail. What tripped me up was I tested with my application/dtmf-relay scenario, it worked and I thought all good. It was only when I tested some other scenario and that part of the code triggered with the wrong value that I wondered why. If it had failed when passed the right value, I would have thought "the function doesn’t do what I want, use another one"

With $cT vs $hdr(Content-Type) is there a preference? Is it just from a readability point of view?

Thanks
Russell

[bogdan-iancu]

My concern is not about the implementation (using int as optimization), but about how the [SUB]TYPE_UNKNOWN is handled - like matching anything, without any warning. This is not ok at all. I may consider falling back (when [SUB]TYPE_UNKNOWN is detected) to string matching, in this case, it will work as expected in all cases....