I was doing some flame graph analysis and found that despite passing a URI into the WebClient, a string version of the URI was being passed into the reactor-netty library where it was parsed again in the UriEndpointFactory: https://github.com/reactor/reactor-netty/blob/dfb1e18551bd51a6cc406acdb923b66c9d7bbada/reactor-netty-http/src/main/java/reactor/netty/http/client/HttpClientConnect.java#L497-L513
Later, the URI is constructed again further inside that library https://github.com/reactor/reactor-netty/blob/dfb1e18551bd51a6cc406acdb923b66c9d7bbada/reactor-netty-http/src/main/java/reactor/netty/http/HttpOperations.java#L429 I may take a stab at cleaning up that in https://github.com/reactor/reactor-netty/issues/829 once the URI is passed from spring. Ideally, I could make the URI passed into spring live all the way thru the lifecycle.
NOTE: this assumes a full URI is present like http://example.com/blah not /blah. When I hit breakpoints here, it appeared that they were all full URI's.
Comment From: rstoyanchev
Thanks for spotting this.
Comment From: yuzawa-san
I recently found that is theoretically possible to have spring generate a non-absolute URI but that would only work if the user was customizing the reactor-netty httpclient to also have a baseUrl. So it is possible, but rare and contradictory to the advice given in the existing javadoc.
// these will call http://localhost/test but will now break
WebClient webClient = WebClient.create();
webClient.get().uri("/test").retrieve().toBodilessEntity().block();
webClient.get().uri(URI.create("/test")).retrieve().toBodilessEntity().block();
this was caused by https://github.com/reactor/reactor-netty/blob/dd366557b172132238bdecc08d7e4c80ca186543/reactor-netty-http/src/main/java/reactor/netty/http/client/UriEndpointFactory.java#L48-L50 but would be prevent now by https://github.com/reactor/reactor-netty/blob/dd366557b172132238bdecc08d7e4c80ca186543/reactor-netty-http/src/main/java/reactor/netty/http/client/UriEndpointFactory.java#L74-L76