WebClient and RestClient should offer a way to customize ClientHttpConnector/ClientHttpRequestFactory rather than replacing it

[snicoll]

Both WebClient and RestClient have a unique hook point to configure the ClientHttpConnector and ClientHttpRequestFactory respectively. There are several convenient features that are inconsistent due to the lack of an abstraction.

MockRestServiceServer is using a mock-based ClientHttpRequestFactory so as soon as you try to configure one in your code, tests no longer bind to the mock server. This is as innocent as the following code (using Spring Boot helper classes):

public class AvailabilityCheckClient {

	private final RestClient client;

	public AvailabilityCheckClient(RestClient.Builder builder, Duration readTimeout) {
		this.client = builder
			.requestFactory(ClientHttpRequestFactories
				.get(ClientHttpRequestFactorySettings.DEFAULTS.withReadTimeout(readTimeout)))
			.build();
	}
        // ...
}

Spring Boot has improved SSL support which is also working via this mechanism. Same situation where everything works as expected up to a point where you need to tune anything on the request factory. See spring-projects/spring-boot#36263.

Courtesy of @wilkinsona, more related issues that provide more context when triaging this.

[snicoll]

Brainstorming with @poutsma, I've tried to give a consumer callback a go, as RestClient.Builder does that in several places already. Something like:

RestClient.Builder requestFactory(Consumer<ClientHttpRequestFactory> requestFactoryConsumer);

Looking at org.springframework.boot.web.client.ClientHttpRequestFactories, depending on the settings and the actual implementation, you may have to provide those in the constructor of the factory so the consumer-based callback does not handle all use cases.

It almost looks like we'd need some sort of backdoor so that the connection factory for the mock server is always taking precedence. The linked spring boot use case is a little different, where auto-configured behavior is lost when creating a ClientHttpRequestFactorySettings instance from scratch to tune settings in user config.

[rstoyanchev]

I think there are two related, but separate issues. One is about multiple parties trying to customize ClientHttpRequestFactory, and the other about MockRestServiceServer depending on a specific factory type.

For the first issue, ClientHttpRequestFactory implementations have a small number of properties themselves, but many more are on the HTTP client, and that's expected to be initialized externally. This is why initialization by multiple parties has to start with a way to configure a shared underlying HTTP client, and that is the goal for spring-projects/spring-boot#41138.

Given a specially configured HTTP client instance, the ClientHttpRequestFactory must be created with it, which means the factory instance must be set on RestClient.Builder. A consumer callback could help to further customize the factory itself, and I'm open to that option, but I think the factory is also better initializated externally, e.g. to allow customization via properties. I think that's the goal for spring-projects/spring-boot#36266 is.

For the second issue, MockRestServiceServer injects a specific request factory type that must not be changed or customized. That RestClient.Builder instance then becomes specific to testing, and must not be shared with alternative types of use. In that sense, spring-projects/spring-boot#38832 (comment) is less a workaround, and more what I would expect, but perhaps Boot's testing support can make this transparent (via customizer as well?) to ensure that the builder for testing is for testing only.

In summary, I see both issues as something that's better solved on the side of Boot.