Here's a minor problem that I found while merging the latest Subscribe Server changes into main: The UtlString::findToken() method is used to look for a string (like "text/plain") in a comma-separated list of strings (like "text/plain,application/octet-stream,text/xml"). The current implementations (plural!) of findToken disagree on whether the specified search string is to be interpreted as a plain text string or a regexp. This message is to get consensus on cleaning up that question and some related issues.
There are only a few uses of findToken now in the code. None of them require that the search string be a regexp. In one of the cases (checking whether a given MIME type is in the Accept list of a SUBSCRIBE request), the search string must not be interpreted as a regexp, since some MIME types have a "+xml" suffix. Thus, I propose interpreting the search string as a plain string rather than a regexp. Actually, I propose this as the default interpretation, and that the regexp interpretation will be available by setting an optional parameter, since the regexp functionality can be added with almost no additional work. Due to the implementation of findToken, the RegEx class needs a method for turning a text string into a regexp string that matches the given string and nothing else, that is, an equivalent to Perl's quotemeta(). Grepping the PCRE documentation (the package underlying the RegEx class) suggests that PCRE contains a quotemeta function, even though RegEx does not expose it. In order to adjust findToken to search for arbitrary plain text strings, it will be necessary for RegEx to expose the quotemeta() operation. Comments & suggestions? Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
