Handle unescaped UTF-8 characters in Presto url_extract_* UDFs #11535
+1,249
−207
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kevinwilfong
requested review from
assignUser and
majetideepak
as code owners
|
This pull request was exported from Phabricator. Differential Revision: D65927918 |
facebook-github-bot
added
CLA Signed
✅ Deploy Preview for meta-velox canceled.
|
kevinwilfong
pushed a commit
to kevinwilfong/velox
that referenced
this pull request
Nov 14, 2024
…ookincubator#11535) Summary: Presto Java supports UTF-8 characters that are not control or whitespace characters appearing anywhere in a URL where a % escaped character can appear. This change modifies Velox's URIParser to do the same. Velox's URIParser would produce incorrect results when any non-ASCII character appeared anywhere in the URL and this has been fixed as well. In order to facilitate this I modified the tryGetCharLength helper function in UTF8Utils to take in a int32_t reference which it populates with the code point if the UTF-8 character is valid. It was already calculating this value and throwing it away, returning it allows me to avoid an additional call to repeat those steps and is consistent with the Airlift function on which it's based. Differential Revision: D65927918
kevinwilfong
force-pushed
the
export-D65927918
branch
from
e4f535f
to
18ee41a
Compare
|
This pull request was exported from Phabricator. Differential Revision: D65927918 |
added 3 commits
November 14, 2024 10:13
…facebookincubator#11488) Summary: Today the Presto URL functions rely on a regex to extract features of a URL. Due to the limitations of regexes this is not sufficient to validate that a URL is indeed valid. This leads to a number of cases where Presto Java will return NULL due to an invalid URL and Velox will return some substring. To address this I've implemented a parser for URIs based on the RFC 3986 spec which can both validate a URL and extract features of it. While testing this change I noticed a number of other discrepancies between Presto Java's and Velox's implementations of these UDFs (mostly related to unescaping/decoding URLs or portions thereof) that had been missed, likely due to the noise from the different handling of invalid URLs. Those are addressed in this diff as well so that I could effectively test it. Differential Revision: D65695961
…bator#11518) Summary: Presto Java converts the URL to a Java String before encoding it in url_encode. Java replaces bytes in an invalid UTF-8 character with 0xEF 0xBF 0xBD. Velox encodes invalid UTF-8 characters as is, which leads to differences in results from Java and C++. This diff adds a check when encoding URLs for invalid UTF-8 characters and does the same replacement as Java. Differential Revision: D65856104
…ookincubator#11535) Summary: Presto Java supports UTF-8 characters that are not control or whitespace characters appearing anywhere in a URL where a % escaped character can appear. This change modifies Velox's URIParser to do the same. Velox's URIParser would produce incorrect results when any non-ASCII character appeared anywhere in the URL and this has been fixed as well. In order to facilitate this I modified the tryGetCharLength helper function in UTF8Utils to take in a int32_t reference which it populates with the code point if the UTF-8 character is valid. It was already calculating this value and throwing it away, returning it allows me to avoid an additional call to repeat those steps and is consistent with the Airlift function on which it's based. Differential Revision: D65927918
kevinwilfong
force-pushed
the
export-D65927918
branch
from
18ee41a
to
8f1e56c
Compare
|
This pull request was exported from Phabricator. Differential Revision: D65927918 |
kevinwilfong
pushed a commit
to kevinwilfong/velox
that referenced
this pull request
Nov 14, 2024
…ookincubator#11535) Summary: Presto Java supports UTF-8 characters that are not control or whitespace characters appearing anywhere in a URL where a % escaped character can appear. This change modifies Velox's URIParser to do the same. Velox's URIParser would produce incorrect results when any non-ASCII character appeared anywhere in the URL and this has been fixed as well. In order to facilitate this I modified the tryGetCharLength helper function in UTF8Utils to take in a int32_t reference which it populates with the code point if the UTF-8 character is valid. It was already calculating this value and throwing it away, returning it allows me to avoid an additional call to repeat those steps and is consistent with the Airlift function on which it's based. Differential Revision: D65927918
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Presto Java supports UTF-8 characters that are not control or whitespace characters appearing
anywhere in a URL where a % escaped character can appear. This change modifies Velox's
URIParser to do the same.
Velox's URIParser would produce incorrect results when any non-ASCII character appeared
anywhere in the URL and this has been fixed as well.
In order to facilitate this I modified the tryGetCharLength helper function in UTF8Utils to take in a
int32_t reference which it populates with the code point if the UTF-8 character is valid. It was
already calculating this value and throwing it away, returning it allows me to avoid an additional call
to repeat those steps and is consistent with the Airlift function on which it's based.
Differential Revision: D65927918