-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(function): Handle unescaped UTF-8 characters in Presto url_extract_* UDFs #11535
Open
kevinwilfong
wants to merge
3
commits into
facebookincubator:main
Choose a base branch
from
kevinwilfong:export-D65927918
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
feat(function): Handle unescaped UTF-8 characters in Presto url_extract_* UDFs #11535
kevinwilfong
wants to merge
3
commits into
facebookincubator:main
from
kevinwilfong:export-D65927918
+1,313
−206
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
November 14, 2024 04:19
This pull request was exported from Phabricator. Differential Revision: D65927918 |
facebook-github-bot
added
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
fb-exported
labels
Nov 14, 2024
✅ 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
November 14, 2024 04:53
e4f535f
to
18ee41a
Compare
This pull request was exported from Phabricator. Differential Revision: D65927918 |
kevinwilfong
force-pushed
the
export-D65927918
branch
from
November 14, 2024 18:14
18ee41a
to
8f1e56c
Compare
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
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
kevinwilfong
force-pushed
the
export-D65927918
branch
from
November 18, 2024 23:12
8f1e56c
to
8a39afe
Compare
kevinwilfong
pushed a commit
to kevinwilfong/velox
that referenced
this pull request
Nov 18, 2024
…tract_* UDFs (facebookincubator#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
This pull request was exported from Phabricator. Differential Revision: D65927918 |
kevinwilfong
changed the title
Handle unescaped UTF-8 characters in Presto url_extract_* UDFs
feature(function): Handle unescaped UTF-8 characters in Presto url_extract_* UDFs
Nov 18, 2024
kevinwilfong
changed the title
feature(function): Handle unescaped UTF-8 characters in Presto url_extract_* UDFs
feat(function): Handle unescaped UTF-8 characters in Presto url_extract_* UDFs
Nov 18, 2024
…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
…ct_* UDFs (facebookincubator#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
November 18, 2024 23:22
8a39afe
to
e0d2168
Compare
This pull request was exported from Phabricator. Differential Revision: D65927918 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
fb-exported
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