When a term which is known to exist and contains a plus sign (e.g. "AO+ Mist" or "R(+)XK469" or "propanoic acid, 2-[4-[(7-chloro-2-quinoxalinyl)oxy]phenoxy}-, (+ )-(R)-") is passed to either autosuggest or search, no results will be found.
This is a leftover from earlier efforts to handle path separators in path-based arguments. At the time, a call to WebUtility.UrlDecode() was added in order to guarantee the path would be decoded properly. When we switched the API back to query string parameters (Issue NCIOCPL/drug-dictionary-app#26), the call was left in place. This has the effect of converting the + into a space, causing the wrong search to occur. (This would most also break searches for names containing a % followed by two hexadecimal digits if the data happened to have any, which it doesn't seem to .)
Issue description
When a term which is known to exist and contains a plus sign (e.g. "AO+ Mist" or "R(+)XK469" or "propanoic acid, 2-[4-[(7-chloro-2-quinoxalinyl)oxy]phenoxy}-, (+ )-(R)-") is passed to either autosuggest or search, no results will be found.
This is a leftover from earlier efforts to handle path separators in path-based arguments. At the time, a call to
WebUtility.UrlDecode()
was added in order to guarantee the path would be decoded properly. When we switched the API back to query string parameters (Issue NCIOCPL/drug-dictionary-app#26), the call was left in place. This has the effect of converting the+
into a space, causing the wrong search to occur. (This would most also break searches for names containing a%
followed by two hexadecimal digits if the data happened to have any, which it doesn't seem to .)Steps to reproduce the issue
What's the expected result?
What's the actual result?
Related Tickets