springboot version 3.2.2 spring-web version

when I user ClientHttpRequestInterceptor to modify URI like this

 @Override
    @SneakyThrows
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {

        HttpRequest newReq = new HttpRequestWrapper(request) {
            @Override
            @SneakyThrows
            public URI getURI() {
                String originUrl = request.getURI().toString();
                String requestUrl = request.getHeaders().getFirst(HEADER_REQUEST_URL);
                return new URI(originUrl.replace(userCenterProperties.getUrl(), requestUrl));
            }
        };

        return execution.execute(newReq, body);
    }

the rootUrl is modified

catch (IOException ex) {
                ResourceAccessException resourceAccessException = createResourceAccessException(uri, this.httpMethod, ex);
                if (observation != null) {
                    observation.error(resourceAccessException);
                }
                throw resourceAccessException;
            }

In DefaultRestClient, when the IoException happened ,will throw ResourceAccessException with rootUri not the expected uri what is modified

Comment From: snicoll

There are two places where the exception is thrown. One if the request failed to be created and there's nothing we can do about that as we don't have access to the object. The second one could use ClientHttpRequest#getURI indeed but it probably done this way for consistency. The URI is included in the exception message, and not exposed as an API so I wouldn't rely on that either.

Let's see what the rest of the team thinks.

Comment From: snicoll

I've discussed this one with @poutsma and he pointed out that RestClient replicates what RestTemplate does to make the switch to one to another easy. The behavior you've described is therefore very old and we can't change it. If you need to tune the URL, perhaps an interceptor is the wrong way to do this and you could create your own request factory rather.

Thanks for the suggestion in any case.