arpitjain099 opened a new pull request, #68370:
URL: https://github.com/apache/doris/pull/68370
### What problem does this PR solve?
Issue Number: none
Problem Summary:
`parse_url` searches for the ':' that separates the port, and the '@' that
separates the userinfo, across the whole url rather than across its authority
component. A ':' or an '@' anywhere in the path, the query or the fragment is
then read as a separator.
```
select parse_url('http://example.com/a:b', 'HOST'); -- example.com/a
select parse_url('http://example.com/a:b', 'PORT'); -- b
select parse_url('http://example.com/a@b:c', 'USERINFO'); -- example.com/a
select parse_url('http://example.com?x=1', 'AUTHORITY'); -- example.com?x=1
```
A ':' in a path segment is legal (RFC 3986 pchar), and Hive resolves these
through `java.net.URL`, which reports host `example.com`, no port and no
userinfo for every one of them. Both of our implementations have it:
`UrlParser::parse_url` in the BE, and `StringArithmetic.parseUrlRaw` in the FE,
which is the constant-folding path and a line-for-line mirror of the BE one.
`AUTHORITY` was the closest to correct, since it already cut at the first '/',
so this routes HOST, PORT and USERINFO through that same step and extends it to
stop at '?' and '#' too.
I could not build the full BE or FE here, so the check was done on the
changed code directly: the BE `url_parser.cpp` was compiled and driven on its
own, and the FE `parseUrl*` methods were extracted and run under a JDK. Before
the change they return the four values above; after it, every case in the new
tests matches what `java.net.URL` reports for the same url.
### Release note
`parse_url` no longer treats a ':' or an '@' outside the authority as a port
or userinfo separator, so `HOST`, `PORT`, `USERINFO` and `AUTHORITY` agree with
`java.net.URL` for urls whose path, query or fragment contains one of those
characters.
### Check List (For Author)
- Test: Unit Test
- `be/test/exprs/function/function_url_test.cpp` and
`fe/fe-core/src/test/.../StringArithmeticTest.java` both gain a case per
affected part. I was not able to run either suite locally, see above.
- Behavior changed: Yes. The four results above change, as described in the
release note. Existing cases in `nereids_function_p0` and
`fold_constant_string_arithmatic` have no ':' or '@' outside the authority, so
they are unaffected.
- Does this need documentation: No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]