[Bug] Uri.parse failes to currectly parse url like: http://user:^@example.com

[idy]

Dart 3.4.3 (stable) (Tue Jun 4 19:51:39 2024 +0000) on "macos_arm64"

Uri.parse is unable to correctly parse cases where the userInfo section contains special characters, such as: http://user:^@example.com

Running the following code:

void main() {
  final u = Uri.parse('http://user:^@example.com');
  print(u.userInfo);
}

The printed log is: user:%5E, but the expected value is: user:^

[dart-github-bot]

Summary: Uri.parse fails to correctly parse URLs with special characters in the userInfo section, incorrectly encoding the ^ character as %5E instead of preserving it.

[svpz]

I think the ^ sign you mentioning is not valid according to the RFC 3986 section 3.2.
As much as I know, the behavior of Uri.parse is consistent with the requirements of RFC 3986. To include special characters like ^ in the userInfo section, they must be percent-encoded. Thus, the method’s output of user:%5E is correct and expected.

[idy]

Yes, RFC 3986 does not define the ^ symbol, so the best approach when parsing it is to leave it unchanged.
According to RFC 3986 section 2.4, only when constructing a URI should the pct-encoded format be used. However, uri.Parse is a dereference.

Thus, the expected behavior is:

Parse(':%[email protected]') returns {username: '', password: '^', ...}
Parse(':^@example.com') returns {username: '', password: '^', ...}

[lrhn]

The behavior is intended.
The alternative would be to reject parsing the input, because it's not a valid URI text. The Dart Uri class tries to help by auto-escaping invalid characters (and normalizes in several ways, including by unescaping unnecessary escapes).

That means that what Uri.toString() returns may not be the original input to Uri.parse, but on the other hand it's guaranteed to be a valid and normalized RFC-3986 URI reference.

[idy]

Thank you for your response. After careful consideration, if the value of userInfo is designed to be in a URL-safe format, then the issue does not arise from Uri.parse; rather, it lies within the HTTP library. When the HTTP request is sent, the pct-encoded value should be decoded and then base64 encoded.

I have raised an issue in the HTTP library. dart-lang/http#1256