Provide configuration properties for common low-level HTTP client settings

[miller79]

Currently, configuring implementation-specific properties for HTTPClient instances—such as idleTimeout or maxConnections—requires custom logic like this:

    @Bean
    public RestClientCustomizer restClientBuilderCustomizer() {
        CloseableHttpClient pooledHttpClient = ...
        ... //Configure the properties here
        return builder -> builder.requestFactory(new HttpComponentsClientHttpRequestFactory(pooledHttpClient));
    }

While I understand the reasoning for not exposing every possible setting for every HTTP client implementation, there are several common properties that could be standardized at a higher level:

• maxConnections
• maxIdleTimeBeforeEviction (when pooling)
• maxLifetime
• keepAlive

These settings are widely applicable across implementations and align closely with what developers expect from other resource pools (e.g., database connection pools).

Libraries like RestEasy have already introduced similar high-level configuration options for their consumers, which simplifies tuning and promotes consistency.

I did a quick search through existing issues and couldn’t find prior discussion on why this hasn’t been considered. I’m curious about the community’s thoughts on introducing a standardized way to configure these common properties across HTTP client implementations.

Edit:

I have created a repository to show the common configs that would be nice to add and how they are configured currently with Apache and Reactor.

https://github.com/miller79/sample-httpclient-configurations

[miller79]

I have created a repository to show the common configs that would be nice to add and how they are configured currently with Apache and Reactor.

https://github.com/miller79/sample-httpclient-configurations

[philwebb]

Thanks for the issue and the sample @miller79. We do currently offer a few common properties that can be configured using spring.http.clients.*, but this is quite a limited set. There's also the ClientHttpRequestFactoryBuilder and ClientHttpConnectorBuilder interfaces that are a bit easier to use than configuring everything directly.

We'll have to discuss this issue after 4.0.0 has been released to see what we want to do. It might be some time before we have a definitive answer.

[miller79]

Sounds good. Definitely not a deal breaker if it doesn't get implemented as there are plenty of alternative solutions. Looking forward to hearing the decision and happy to help if I can.

[miller79]

@philwebb thanks for the info on the other interfaces. I've updated my sample to use those details now just to keep it as tight as possible for discussion purposes in the future.