[
https://issues.apache.org/jira/browse/CALCITE-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-7600:
------------------------------------
Labels: pull-request-available (was: )
> 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
> Priority: Major
> Labels: pull-request-available
>
> ## 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)
