-
Notifications
You must be signed in to change notification settings - Fork 38.5k
UriComponentsBuilder silently drops some Registry-based Naming Authorities #27774
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
I'm not quite sure what your are proposing or what you mean with re-parsing. If understand, when the source is a Overall, If the current spec doesn't support the concept of a non-server authority, I'm not sure we need to support it UriComponentsBuilder. |
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
This is certainly complicated! Thank you for being patient while I try to explain my understanding.
My analysis is that the I attempted to demonstrate this through showing how As far as "re-parsing", I was simply suggesting a solution. If you agree that the current behavior is unexpected then I can write a PR and we can more directly discuss the possible solution.
|
It is surprising that Closing this one but feel free to submit a PR and reference this issue. |
In spring-web 5.3.13, UriComponentsBuilder.fromUri / UriComponentsBuilder.uri silently drops some RFC 2396 3.2.1 Registry-based Naming Authorities even when they are accepted as RFC 3986 3.2 authorities.
When
java.net.URI
encounters an RFC 2396 3.2.1 authority (identified as any correct authority not parseable under RFC 2396 3.2.2), it returns null values for the server-based naming authority components, causingUriComponentBuilder
to assume they are unset and silently dropping the data. However, this data is available viaURI.getAuthority()
.I would expect that
UriComponentBuilder
would attempt to reparse the authority fromUri.getAuthority
under the RFC 3986 3.2 specification.The fact that these classes are written against different versions of the spec is obviously a complicating factor. The most straightforward option is to reparse the URI from scratch under the RFC 3986 spec, though I think that it would be preferable to only parse the authority component to limit the blast radius of this change. I am happy to contribute a PR, but would appreciate thumbs up on the approach before investing the time as this would substantially change existing behavior if
UriComponentBuilder.uri
is being used after the authority components have been set via another method.The text was updated successfully, but these errors were encountered: