Strip query string from uri low-cardinality key in DefaultClientRequestObservationConvention

[anuragg-saxenaa]

Summary

extractPath() in DefaultClientRequestObservationConvention stripped the scheme and host but preserved the query string. When HTTP Interface clients (@HttpExchange) use @RequestParam parameters, Spring injects URI template placeholders like {queryParam-category} into the query string. Because these differ per combination of present/absent optional parameters and per list length, the uri low-cardinality tag inherits combinatorial or even unbounded cardinality — defeating the purpose of the tag and causing Prometheus metric explosion.

Changes

• spring-web DefaultClientRequestObservationConvention.extractPath(): strip everything from ? onward
• spring-webflux DefaultClientRequestObservationConvention.extractPath(): same fix

Path template variables ({id}) continue to be preserved since they identify distinct endpoint routes. The full URI (including query string) is already captured in the http.url high-cardinality key, so no observability information is lost.

Behavior change

Before:

uri="/resource/{id}?queryKey={queryValue}"    (high cardinality — varies per param combination)

After:

uri="/resource/{id}"    (low cardinality — matches server-side behavior)

This is consistent with how server-side @RequestMapping with @RequestParam already behaves (uri="/api/v1/items" regardless of query parameters).

Fixes #36547

[bclozel]

Declining because this would be breaking behavior. See #36547 (comment)

[anuragg-saxenaa]

Thanks for the explanation @bclozel — you're right, stripping query params globally would break valid use cases like /users?profile=full being intentionally tracked as a distinct URI pattern.

The cardinality issue is specific to @HttpExchange auto-generating {queryParam-*} placeholders. A more targeted fix would indeed belong there rather than in the observation convention. Closing this PR.