-
Notifications
You must be signed in to change notification settings - Fork 38.5k
UriComponentsBuilder.fromUriString may not parse correctly when there is no path [SPR-11970] #16586
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
Comments
Rossen Stoyanchev commented The trigger for this seems to be (a) no path and (b) the presence of an "@" in the query or fragment. Most likely the USERINFO_PATTERN in UriComponentsBuilder needs to be updated. |
Kazuki Shimizu commented "?" add as exclude character !? Current private static final String USERINFO_PATTERN = "([^@/]*)"; Modify candidate private static final String USERINFO_PATTERN = "([^@/?]*)"; |
Kazuki Shimizu commented Hi Brian. Thank you for resolved. I have a question. |
Brian Clozel commented We're ignoring the following chars because:
|
Kazuki Shimizu commented Thank you for answer. This means that is can be specify the '@' character in the IPv6 address ? Specifications of rfc3986
|
Brian Clozel commented No, it just means that the userinfo part "user:password" should not contain the following chars ( Here is a complete example:
Here I marked with |
Kazuki Shimizu commented Thank you very*2 much for answer. In my understanding, URI parts that can be specify private static final String USERINFO_PATTERN = "([^/?#]*)"; This understanding is wrong ? |
Rossen Stoyanchev commented But the "@" is what separates the user info from the host. So you want to stop right there, no? |
Kazuki Shimizu opened SPR-11970 and commented
e.g.) "http://example.com?..." and "http://example.com/?..." has different behavior.
For following example...
If not specify path in uri, string of up to '@' in the query parameters is recognized as a UserInfo.
Test code
Console
If specify path in uri, result are following.
Before and after is same. (this behavior is correct.)
Affects: 3.2.9, 4.0.5
Backported to: 3.2.11
The text was updated successfully, but these errors were encountered: