Inconsistent inclusion of base URL in `WebClient` URI template attribute since Spring WebFlux 6.1.2

[breun]

Consider this code:

String URI_TEMPLATE_ATTRIBUTE = WebClient.class.getName() + ".uriTemplate";

WebClient webClient = WebClient.builder()
        .baseUrl("http://example.com")
        .build();

webClient.get()
        .uri("/foo/{id}", Map.of("id", 1))
        .attributes(attributes ->
                System.out.println("URI template when using a Map: " + attributes.get(URI_TEMPLATE_ATTRIBUTE))
        );

webClient.get()
        .uri("/foo/{id}", 1)
        .attributes(attributes ->
                System.out.println("URI template when using varargs: " + attributes.get(URI_TEMPLATE_ATTRIBUTE))
        );

With Spring Framework 6.1.1 this prints the following:

URI template when using a Map: /foo/{id}
URI template when using varargs: /foo/{id}

However, with Spring Framework 6.1.2 the output is this:

URI template when using a Map: /foo/{id}
URI template when using varargs: http://example.com/foo/{id}

So, when using varargs the baseUrl is now included in the URI template, but when using a Map it isn't.

It seems the change to include the base URL in the URI template was made via #30027. I personally have doubts about whether the base URL should be included in the URI template. I'd like to have access to the URI template as it was passed to the client and I'd prefer the base URL not to be included, because it clutters our distributed tracing output. The base URL could be passed via a separate attribute maybe?

But if this change to suddenly include the base URL in the URI template attribute is indeed intentional, it seems it was at least not consistently implemented.

[poutsma]

FYA @rstoyanchev

[rstoyanchev]

The change is intentional as per #30027. The baseUrl makes the URL complete and potentially unique if there is more than one WebClient, but I do understand sometimes the baseUrl is not of interest. A separate attribute wouldn't help much as the built-in observation support would still need to decide whether to include it or not. We would need a config option to control the behavior if necessary.

You're right the change wasn't applied consistently. I'll fix that.