Alhuda Khan created CALCITE-7600:
------------------------------------
Summary: quote parse_url key before building the query regex
Key: CALCITE-7600
URL: https://issues.apache.org/jira/browse/CALCITE-7600
Project: Calcite
Issue Type: Bug
Reporter: Alhuda Khan
## Jira Link A Jira can be filed for this if preferred; raising the patch first
since the change is a small, self-contained fix. ## Changes Proposed `Repro:`
`parse_url('http://h/p?k1=v1&k2=v2', 'QUERY', 'k.')` and
`parse_url('http://h/p?k1=v1', 'QUERY', '(')`. `Expected:` the first returns
`NULL` (no parameter is literally named `k.`); the second returns `NULL` (no
parameter named `(`). `Actual:` `ParseUrlFunction.keyToPattern` builds the
lookup with `Pattern.compile("(&|^)" + keyToExtract + "=([^&]*)")`, so the key
is spliced into the regex unescaped. The key is the third `PARSE_URL` argument
and crosses the trust boundary. Regex metacharacters in the key are
interpreted, so `k.` matches `k1` and wrongly returns `v1`, and a key that is
not a valid regex such as `(` throws `PatternSyntaxException` out of the
function instead of yielding a result. `Fix:` wrap the key in `Pattern.quote`
so it is matched literally, which is the documented key semantics.
`Pattern.quote` is already the idiom used elsewhere in `SqlFunctions` (the
`split` helper). `Test:` `SqlOperatorTest.testParseUrl` gains cases for a
metacharacter key and a non-regex key; both fail on the unpatched tree and pass
after.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
