You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HttpClient5 update packaged from Spring Boot 3.4/Spring Cloud 2024.0.0 + Envoy causing unexpected behaviours from 'protocolUpgradeEnabled' configuration #738
Spring Boot 3.4.0
Spring Cloud Dependencies 2024.0.0 (Spring Cloud Starter Vault Config 4.2.0, Spring Cloud Vault Config 4.2.0)
Spring Vault Core 3.1.2 HttpClient5 5.4.1
Istio Envoy
This is a noted issue in the Spring Boot 3.4 Release notes, where Envoy is unable to parse the HTTP/1.1 TLS upgrades which were made the default as part of the current version of HttpClient5.
From the ClientHttpRequestFactoryFactory class within Spring Vault Core, given that Apache HttpComponents dependency exists, it would be the default client used for constructing the ClientHttpRequestFactory that is inadvertently used by VaultTemplate to create requests to Vault.
However, with reference to this issue raised on Istio, the ClientHttpRequestFactory spun up by ClientHttpRequestFactoryFactory has protocolUpgradeEnabled = true by default.
The resolution provided in the Spring Boot Release notes to define this bean to supersede the new defaults does not seem to be working as expected, as the Spring Vault instantiation happens before the Bean is registered.
Ultimately, this causes requests from VaultTemplate -> Istio -> Vault to fail.
From what I see, the VaultConfigDataLoader class registers the clientHttpRequestFactory bean if its absent, and at this point in the bootstrap, there isn't a clientHttpRequestFactory instance yet.
Code below for reference. Please do advise if I'm misconfiguring this.
@SpringBootApplication
@Slf4j
public class VaultTestApplication {
public static void main(String[] args) {
SpringApplication application = new SpringApplication();
application.addBootstrapRegistryInitializer(
registry -> {
registry.registerIfAbsent(AbstractVaultConfiguration.ClientFactoryWrapper.class, ctx -> {
HttpComponentsClientHttpRequestFactory factory = ClientHttpRequestFactoryBuilder.httpComponents()
.withDefaultRequestConfigCustomizer(builder -> builder.setProtocolUpgradeEnabled(false)).build();
return new AbstractVaultConfiguration.ClientFactoryWrapper(factory);
});
});
SpringApplication.run(VaultTestApplication.class);
}
}
Have you noticed that you're not using the customized application object, but instead, you're running SpringApplication.run(VaultTestApplication.class);? It should be application.run(args).
@mp911de An example with application.addBootstrapRegistryInitializer() doesn't work even corrected. addBootstrapRegistryInitializer() just adds InstanceSupplier not a bean.
And that InstanceSupplier never called because AbstractVaultConfiguration.ClientFactoryWrapper is already created during bootstrap.
I am using bootstrap.yaml for Vault configuration.
I am using bootstrap.yaml for Vault configuration.
This is an important detail because in that case, you need to define an override bean (@Bean ClientFactoryWrapper). To do so, create a boostrap autoconfiguration and register it with spring.factories under the org.springframework.cloud.bootstrap.BootstrapConfiguration key.
@mp911de Even after adding the following fix , I still dont see the issue fixed , should I turn on the property spring.main.allow-bean-definition-overriding: true as well ?
We are not using Spring's Vault then should we still follow the suggestion you mentioned earlier , ie
This is an important detail because in that case, you need to define an override bean (@bean ClientFactoryWrapper). To do so, create a boostrap autoconfiguration and register it with spring.factories under the org.springframework.cloud.bootstrap.BootstrapConfiguration key.
Activity
mp911de commentedon Dec 10, 2024
You can register a
ClientHttpRequestFactorywrapped inorg.springframework.vault.config.AbstractVaultConfiguration.ClientFactoryWrapper:Let me know whether this helps.
Mingkongchan0 commentedon Dec 11, 2024
Hi @mp911de, I don't think it works.
From what I see, the
VaultConfigDataLoaderclass registers theclientHttpRequestFactorybean if its absent, and at this point in the bootstrap, there isn't aclientHttpRequestFactoryinstance yet.Code below for reference. Please do advise if I'm misconfiguring this.
mp911de commentedon Dec 11, 2024
Have you noticed that you're not using the customized
applicationobject, but instead, you're runningSpringApplication.run(VaultTestApplication.class);? It should beapplication.run(args).v-ladynev commentedon Dec 12, 2024
@mp911de An example with
application.addBootstrapRegistryInitializer()doesn't work even corrected.addBootstrapRegistryInitializer()just addsInstanceSuppliernot a bean.And that
InstanceSuppliernever called becauseAbstractVaultConfiguration.ClientFactoryWrapperis already created during bootstrap.I am using
bootstrap.yamlfor Vault configuration.mp911de commentedon Dec 13, 2024
This is an important detail because in that case, you need to define an override bean (
@Bean ClientFactoryWrapper). To do so, create a boostrap autoconfiguration and register it withspring.factoriesunder theorg.springframework.cloud.bootstrap.BootstrapConfigurationkey.v-ladynev commentedon Dec 13, 2024
@mp911de It works. Thank you very much.
Also this configuration parameter should be added to
bootstrap.yamlreachjyo commentedon Dec 17, 2024
@mp911de Even after adding the following fix , I still dont see the issue fixed , should I turn on the property
spring.main.allow-bean-definition-overriding: trueas well ?We are not using Spring's Vault then should we still follow the suggestion you mentioned earlier , ie