Vitor Dantas created HTTPCLIENT-2315:
----------------------------------------
Summary: Inconsistent observance of system properties when using
HttpClients.createSystem
Key: HTTPCLIENT-2315
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2315
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient (classic)
Affects Versions: 5.3
Reporter: Vitor Dantas
During the startup of my application, I configure an SSLContext with additional
certificates and set it as a global default using SSLContext.setDefault.
Subsequently, all requests created without explicit configuration can
successfully connect to servers requiring these certificates. This setup
functions seamlessly with various APIs I currently utilize:
* java.net.URLConnection (e.g., URLConnection conn = url.openConnection())
* java.net.http.HttpClient (e.g., HttpClient client =
HttpClient.newHttpClient())
* org.springframework.ws.client.core.WebServiceTemplate (e.g.,
WebServiceTemplate webServiceTemplate = new WebServiceTemplate())
Previously, this approach worked flawlessly with
org.apache.httpcomponents:httpclient:4.5.14, where clients were created using:
HttpClient httpclient = org.apache.http.impl.client.HttpClients.createSystem();
However, issues arise (due to missing certificates) after upgrading to
org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with:
HttpClient httpclient =
org.apache.hc.client5.http.impl.classic.HttpClients.createSystem();
When creating a client with
HttpClientBuilder.create().useSystemProperties().build() or more succinctly
with HttpClients.createSystem(), the expectation is that system properties are
observed throughout.
However, upon inspecting the code, it becomes evident that the connection
manager underneath is created using
PoolingHttpClientConnectionManagerBuilder.create().build(), and not
PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build()
as one might anticipate.
Consequently, an internal condition registers the HTTPS socketFactory using
SSLConnectionSocketFactory.getSocketFactory() instead of
SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results in
the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) instead of
leveraging the default one through SSLSocketFactory.getDefault().
Why is this the case? Is it possible to change this behavior so that the
configuration is simplified when one aims to use the default socket factory
configured through system properties? Specifically, without the need for
explicit configuration of the connection manager in such a common scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
