Inconsistency between toUriString and toUri of UriComponents

[anaconda875]

Hi Spring Team,

		String addr = "a@b.com";
		String encodedAddr = URLEncoder.encode(addr, StandardCharsets.UTF_8);
		UriComponents uriComponents = UriComponentsBuilder.fromUriString("http://localhost:8080/emails/{email}")
				.uriVariables(Map.of("email", encodedAddr))
				.build();

		System.out.println(uriComponents.toUriString());
		System.out.println(uriComponents.toUri());

Above code will print

http://localhost:8080/emails/a%40b.com
http://localhost:8080/emails/a%2540b.com

This is because, the UriComponentsBuilder.buildInternal(EncodingHint hint) was called with the hint was EncodingHint.NONE. After that, HierarchicalUriComponents.expand(UriTemplateVariables uriVariables) called and the a%40b.com was placed to the {email} placeholder without any encoding. Finally, uriComponents.toUriString() did nothing, but just concaternate scheme, host, path, etc together to produced http://localhost:8080/emails/a%40b.com.
In case of uriComponents.toUri(), the constructor java.net.URI#URI(java.lang.String, java.lang.String, java.lang.String, int, java.lang.String, java.lang.String, java.lang.String) called, which encoded the a%40b.com again, so we got http://localhost:8080/emails/a%2540b.com
Proposal: Consider if EncodingHint#NONE provided, then call new URI(toUriString()); instead

[rstoyanchev]

Do you need to encode URI variables externally vs using the built-in encoding?

String addr = "a@b.com";
UriComponents uriComponents = UriComponentsBuilder.fromUriString("http://localhost:8080/emails/{email}")
		.uriVariables(Map.of("email", addr))
		.encode(StandardCharsets.UTF_8)
		.build();

When .encode() isn't called, we don't know that it is already encoded.

[anaconda875]

it looks ok, but the original case still have Inconsistency, right?

[rstoyanchev]

From the perspective of UriComponents, the components are not encoded, and has no way of knowing they were encoded externally.

EncodingHint.NONE just means we shouldn't apply encoding on our end, but that does not mean components are encoded or not encoded. That's not good enough to make a decision.

We would need another encoding mode, but given that use of the built-in encoding works, I don't see a good reason to make further changes.