Avoid redundant URI object creation in WebClientUtils

[MintBee]

Resolve issue 36605

Problem

WebClientUtils.getRequestDescription() constructed a new URI via the
multi-arg constructor on every call just to strip query parameters for logging.
This re-parses and re-validates what the input URI already parsed.

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/function/client/WebClientUtils.java

Lines 75 to 83 in 2ee4c3a

	public static String getRequestDescription(HttpMethod httpMethod, URI uri) {
	if (StringUtils.hasText(uri.getQuery())) {
	try {
	uri = new URI(uri.getScheme(), null, uri.getHost(), uri.getPort(), uri.getPath(), null, null);
	}
	catch (URISyntaxException ignored) {
	}
	}
	return httpMethod.name() + " " + uri;

Changes

Replace new URI(scheme, null, host, port, path, null, null) with direct
StringBuilder composition from the original URI's components. The
reconstruction logic follows JDK's own URI.defineString(), minus the
userInfo, query, and fragment fields — including its IPv6 bracket
handling. Since the URI spec (RFC 3986) has been stable since 2005, this
component-to-string mapping is unlikely to break.

Also switched from StringUtils.hasText(uri.getQuery()) to
uri.getRawQuery() != null for a more performant query presence check. (no decoding needed)

Performance

JMH (JDK 21, @Fork(2), 5w+10m iterations) on the full
WebClient.get().uri(...).retrieve().toBodilessEntity().block() pipeline
with a no-op connector and a 200+ char query-heavy URI:

Version	ops/s	99.9% CI
Baseline (new URI(...))	79,985 ± 19,649	[60,335 — 99,635]
Patched (StringBuilder)	100,942 ± 18,521	[82,421 — 119,464]
Speedup	1.26×

JFR confirms: URI$Parser execution samples dropped 86%, and
getRequestDescription itself drops to 0 samples (below ~10ms threshold).

Tests

Added WebClientUtilsTests for regression testing, covering various situations.

[bclozel]

Could we consider adding httpMethod.name() and the " " at the beginning to the StringBuilder directly? Using a Srting builder to then perform two concatenations is a bit wasteful.

[bclozel]

in the original issue, you added a comment about this: I think we should indeed strip the user info from the logged URI. Can you update the implementation to check for the presence of raw user info?

[MintBee]

Should I strip the fragment too when only the fragment is in presence for the URI? I guess we should, since this is more consistent with existing API, and the purpose of the method is purely for logging.

[bclozel]

Could explain why the path needs decoding? I think using the raw path would be consistent with URI#toString().

[MintBee]

There were two reasons.

1. Since it was for logging, I though decoded path is more readable.
2. Controller annotations take decoded string, such as @GetMapping("/hello world"). I though it would be more consistent with the overall API.

I should've made a comment about it. I was too focused on only describing the performance parts. Thanks for pointing that @bclozel

Should I rollback and return the encoded string?